#304: Stack abstraction inconsistency between Java and Lisp frames -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.2.0 Component: interpreter | Version: 1.2.0-dev Keywords: needs-test | -------------------------+-------------------------------------------------- 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.
#304: Stack abstraction inconsistency between Java and Lisp frames -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.2.0 Component: interpreter | Version: 1.2.0-dev Keywords: has-test | -------------------------+-------------------------------------------------- Changes (by mevenson):
* keywords: needs-test => has-test
Comment:
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 }}}
#304: Stack abstraction inconsistency between Java and Lisp frames --------------------------+------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: closed Priority: major | Milestone: 1.2.0 Component: interpreter | Version: 1.2.0-dev Resolution: fixed | Keywords: has-test --------------------------+------------------------------------------------- Changes (by mevenson):
* status: new => closed * resolution: => fixed
Comment:
(In [14406]) The LispThread stack no longer grows inconsistently from errors thrown in implementation Java code.
Fixes #304.
armedbear-ticket@common-lisp.net