Compilation failure from stack inconsistency

[Mark Evenson]

#|
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

|#

[Mark Evenson]

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.

[ehuelsmann]

We have a compiler component now. Set it.

[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

2. 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.

[ehuelsmann]

Fix for part 1 committed.

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

[ehuelsmann]

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.

[Mark Evenson]

The "fix for part 1" was r11837.

[ehuelsmann]

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.