#114: Strange backtrace growth ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- Armed Bear Common Lisp 0.23.0-dev Java 1.5.0_11 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.71 seconds. Startup completed in 2.53 seconds. Type ":help" for a list of available commands. CL-USER(1): foo #<THREAD "interpreter" {6D3B92}>: Debugger invoked on condition of type UNBOUND-VARIABLE The variable FOO is unbound. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): :bt 100
0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNBOUND-VARIABLE FOO {388C74}>) 2: org.armedbear.lisp.Lisp.pushJavaStackFrames(Lisp.java:332) 3: org.armedbear.lisp.Lisp.error(Lisp.java:353) 4: org.armedbear.lisp.Lisp.eval(Lisp.java:457) 5: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:343) 6: (SYSTEM::%EVAL FOO) 7: (EVAL FOO) 8: (SYSTEM:INTERACTIVE-EVAL FOO) 9: (TOP-LEVEL::REPL) 10: (TOP-LEVEL::TOP-LEVEL-LOOP)[1] CL-USER(3): 0 CL-USER(4): foo #<THREAD "interpreter" {6D3B92}>: Debugger invoked on condition of type UNBOUND-VARIABLE The variable FOO is unbound. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): :bt 100
0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNBOUND-VARIABLE FOO {1E492D8}>) 2: org.armedbear.lisp.Lisp.pushJavaStackFrames(Lisp.java:332) 3: org.armedbear.lisp.Lisp.error(Lisp.java:353) 4: org.armedbear.lisp.Lisp.eval(Lisp.java:457) 5: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:343) 6: (SYSTEM::%EVAL FOO) 7: (EVAL FOO) 8: (SYSTEM:INTERACTIVE-EVAL FOO) 9: (TOP-LEVEL::REPL) 10: (SYSTEM::%EVAL FOO) 11: (EVAL FOO) 12: (SYSTEM:INTERACTIVE-EVAL FOO) 13: (TOP-LEVEL::REPL) 14: (TOP-LEVEL::TOP-LEVEL-LOOP)[1] CL-USER(6): 0 CL-USER(7): foo #<THREAD "interpreter" {6D3B92}>: Debugger invoked on condition of type UNBOUND-VARIABLE The variable FOO is unbound. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(8): :bt 100
0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNBOUND-VARIABLE FOO {164DE59}>) 2: org.armedbear.lisp.Lisp.pushJavaStackFrames(Lisp.java:332) 3: org.armedbear.lisp.Lisp.error(Lisp.java:353) 4: org.armedbear.lisp.Lisp.eval(Lisp.java:457) 5: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:343) 6: (SYSTEM::%EVAL FOO) 7: (EVAL FOO) 8: (SYSTEM:INTERACTIVE-EVAL FOO) 9: (TOP-LEVEL::REPL) 10: (SYSTEM::%EVAL FOO) 11: (EVAL FOO) 12: (SYSTEM:INTERACTIVE-EVAL FOO) 13: (TOP-LEVEL::REPL) 14: (SYSTEM::%EVAL FOO) 15: (EVAL FOO) 16: (SYSTEM:INTERACTIVE-EVAL FOO) 17: (TOP-LEVEL::REPL) 18: (TOP-LEVEL::TOP-LEVEL-LOOP)[1] CL-USER(9): 0 CL-USER(10):
#114: Strange backtrace growth -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment(by mevenson):
The problem is much worse with SLIME, which I had assumed was an artifact of the SLIME interface code rather than the ABCL implementation.
#114: Strange backtrace growth -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: closed Priority: major | Milestone: Component: other | Version: Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Changes (by mevenson):
* status: new => closed * resolution: => fixed
Comment:
The backtrace growth occurs when Lisp.pushJavaStackFrames() inadvertently pushes frames to the stack that are not part of the error visible to consumers of the stack interface (i.e. the JavaStackFrames are "internal" to the implementation). This occurs because the current logic in pushJavaStackFrames() of looking for the first call from org.armedbear.lisp.Primitives does not cover these sort of code paths.
r13108 contains a fix for the bug reported in the ticket, but without a more comprehensive audit, we cannot say that this issue is definitively fixed. But I will close the issue for now, in the absence of other failing cases
armedbear-ticket@common-lisp.net
-
armedbear