Opened 13 years ago

Closed 12 years ago

Last modified 11 years ago

#21 closed defect (fixed)

Compilation failure from stack inconsistency

Reported by: Mark Evenson Owned by: ehuelsmann
Priority: major Milestone: 0.22
Component: compiler Version: 1.0
Keywords: Cc:
Parent Tickets:


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:


Change History (7)

comment:1 Changed 13 years ago by 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.

comment:2 Changed 12 years ago by ehuelsmann

Component: othercompiler
Owner: changed from somebody to ehuelsmann

We have a compiler component now. Set it.

comment:3 Changed 12 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
  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 12 years ago by ehuelsmann

Fix for part 1 committed.

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

comment:5 Changed 12 years ago by ehuelsmann

Resolution: fixed
Status: newclosed

Looking at, 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 11 years ago by Mark Evenson

The "fix for part 1" was r11837.

comment:7 Changed 11 years ago by ehuelsmann

Milestone: unscheduled0.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.