Opened 6 years ago

Closed 5 years ago

Last modified 4 years ago

#21 closed defect (fixed)

Compilation failure from stack inconsistency

Reported by: mevenson Owned by: ehuelsmann
Priority: major Milestone: 0.22
Component: compiler Version: 1.0
Keywords: Cc:

Description

#|
Eric Marsden on armedbear-j-devel
|#

(defun foo ()

(flet ((bar () (unwind-protect 1 2)))

(declare (inline bar))
(undefined (bar))))

#|

; Compiling /Users/evenson/work/abcl/bugs/stack-inconsistency.lisp ...
Stack inconsistency at index 24: found 3, expected 1.

; Compilation unit finished
; The following functions were used but not defined:
; UNDEFINED

|#

Change History (7)

comment:1 Changed 6 years ago by mevenson

Eric Marsden originally reported the bug as failing on the "[o]penJDK on Linux. The stack error is also detected by Kaffe.", but the bug exhibits itself under x86-darwin-9.5.0 jdk-1.5.0_16 and x86-solaris-5.11.snv_79a jdk-1.6.0_10. The error message is coming from ABCL's own java bytecode, so there is no reason to suspect that this is dependent on the Java version.

comment:2 Changed 6 years ago by ehuelsmann

  • Component changed from other to compiler
  • Owner changed from somebody to ehuelsmann

We have a compiler component now. Set it.

comment:3 Changed 6 years ago by ehuelsmann

The issue in this ticket is 2-fold:

  1. It's related to JSR and RET, which cannot be verified reliably by the bytecode verifier, as per http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4381996
  1. The JVM clears the stack when raising an exception, meaning that even if the handler successfully recovers, there's no way to continue where we left off, for example when an unwind-protect or handler-case is used as a function argument.

comment:4 Changed 5 years ago by ehuelsmann

Fix for part 1 committed.

This eliminates the error seen when compiling the code provided above.

comment:5 Changed 5 years ago by ehuelsmann

  • Resolution set to fixed
  • Status changed from new to closed

Looking at http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#15494, which does talk about branching to a routine with handlers for the right type of exception, but doesn't talk about clearing the stack (and lacking any references on this ticket), I'm going to close for now. Please reopen when appropriate.

comment:6 Changed 5 years ago by mevenson

The "fix for part 1" was r11837.

comment:7 Changed 4 years ago by ehuelsmann

  • Milestone changed from unscheduled to 0.22

Part two must have gotten fixed some time, because current trunk does not exhibit this error. There is "unsafe-p" rewriting code in compiler-pass1 which is supposed to address exactly this issue, I've come to understand.

Anyway, closed is not 'unscheduled'; moving to the most recently closed milestone.

Note: See TracTickets for help on using tickets.