Strange backtrace growth

[ehuelsmann]

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$pfeval.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$pfeval.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$pfeval.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):

[Mark Evenson]

The problem is much worse with SLIME, which I had assumed was an artifact of the SLIME interface code rather than the ABCL implementation.

[Mark Evenson]

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