#21: Compilation failure from stack inconsistency ------------------------+--------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: unscheduled Component: component1 | Version: 1.0 Keywords: | ------------------------+--------------------------------------------------- #| 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
|#
#21: Compilation failure from stack inconsistency -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: unscheduled Component: component1 | Version: 1.0 Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment(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.
#21: Compilation failure from stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: compiler | Version: 1.0 Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by ehuelsmann):
* owner: somebody => ehuelsmann * component: other => compiler
Comment:
We have a compiler component now. Set it.
#21: Compilation failure from stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: compiler | Version: 1.0 Resolution: | Keywords: -----------------------+----------------------------------------------------
Comment(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
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.
#21: Compilation failure from stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: compiler | Version: 1.0 Resolution: | Keywords: -----------------------+----------------------------------------------------
Comment(by ehuelsmann):
Fix for part 1 committed.
This eliminates the error seen when compiling the code provided above.
#21: Compilation failure from stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: closed Priority: major | Milestone: unscheduled Component: compiler | Version: 1.0 Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by ehuelsmann):
* status: new => closed * resolution: => fixed
Comment:
Looking at http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#15..., 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.
#21: Compilation failure from stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: closed Priority: major | Milestone: unscheduled Component: compiler | Version: 1.0 Resolution: fixed | Keywords: -----------------------+----------------------------------------------------
Comment(by mevenson):
The "fix for part 1" was r11837.
#21: Compilation failure from stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: closed Priority: major | Milestone: 0.22 Component: compiler | Version: 1.0 Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by ehuelsmann):
* milestone: unscheduled => 0.22
Comment:
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.
armedbear-ticket@common-lisp.net
-
armedbear