Opened 12 years ago

Closed 12 years ago

#304 closed defect (fixed)

Stack abstraction inconsistency between Java and Lisp frames

Reported by: Mark Evenson Owned by: ehuelsmann
Priority: major Milestone: 1.2.0
Component: interpreter Version: 1.2.0-dev
Keywords: has-test Cc:
Parent Tickets:

Description

The stack abstraction maintained by LispThread?.java can get very large, seemingly containing a frames that should long ago have been popped.

I believe this is happening when we push "Java stack frames" via Lisp.pushJavaStackFrame() when some part of the implementation calls Lisp.error(). These frames are never cleaned up properly by an appropriate pop.

Instead of pushing this information to the LispThread? stack, the information could possibly be added to the appropriate Lisp frame to be output in a backtrace.

Change History (2)

comment:1 Changed 12 years ago by Mark Evenson

Keywords: has-test added; needs-test removed

How to increase the length of the current backtrace:

CL-USER> (length (sys:backtrace))
73
CL-USER> (pathname "file:")
; Evaluation aborted on #<SIMPLE-ERROR {33B96470}>.
CL-USER> (length (sys:backtrace))
83

comment:2 Changed 12 years ago by Mark Evenson

Resolution: → fixed
Status: new → closed

(In [14406]) The LispThread? stack no longer grows inconsistently from errors thrown in implementation Java code.

Fixes #304.

Note: See TracTickets for help on using tickets.