Opened 14 years ago

Closed 14 years ago

#114 closed defect (fixed)

Strange backtrace growth

Reported by: ehuelsmann Owned by: somebody
Priority: major Milestone:
Component: other Version:
Keywords: Cc:
Parent Tickets:

Description

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):

Change History (2)

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

comment:2 Changed 14 years ago by Mark Evenson

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.