armedbear-devel December 2016

armedbear-devel@common-lisp.net

4 participants
5 discussions

disabling debugger in production
by Vibhu Mohindra 26 Apr '17

26 Apr '17

I'm bundling up a program for distribution to customers. I don't want it to ever enter the debugger. I want it to raise Java exceptions instead. What I've written to achieve this follows. I've observed it working. However, there are still times when my program enters the debugger. I can't tell why, and want to prevent it entirely. Does anybody know? Does anyone on this list distribute ABCL applications to end users, and how do you disable the debugger? /* disable the debugger. raise a RuntimeException instead */ static void installDebuggerHook() { Symbol.DEBUGGER_HOOK .setSymbolValue(new Function() { public LispObject execute(LispObject c, LispObject h) { throw translateCondition(c);}}); } static RuntimeException translateCondition(LispObject c) { return new RuntimeException( c instanceof Condition ? String.format("%s: %s", c.princToString(), ((Condition) c).getConditionReport()) : c.princToString()); } My program is really a Lisp library that people will use via a thin Java layer. I have a hunch that the above takes care of errors that occur in: interpreter.eval("...") but not errors that occur in: someSymbol.execute(...) Thanks in advance, Vibhu

1 2

Anyone understand the logic of pushJavaStackFrames
by Alan Ruttenberg 09 Jan '17

09 Jan '17

I'm getting backtraces that are noisy and therefore impede comprehension. For example, in the following stack trace, frames 68-4 seem to recapitulate, for the most part, the java stack corresponding to frames 87-69 Thanks, Alan The value CL-UTILS::FORMS is not of type LIST. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY] Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "jnil" "cl-utils">. 1: [ACCEPT] Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "jnil" "cl-utils"> as having been successful. 2: [RETRY] Retry ASDF operation. 3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 4: [ABORT] Abort compilation. 5: [*ABORT] Return to SLIME's top level. --more-- Backtrace: 0: (#<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}> #<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>) 1: (APPLY #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}> (#<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {D3CDE50}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 6: org.armedbear.lisp.LispObject.car(LispObject.java:165) 7: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 8: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 10: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 11: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 12: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 13: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 14: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 15: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 16: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 17: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 18: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 19: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 20: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 21: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 22: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 23: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 24: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 25: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 26: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 27: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 28: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 29: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 30: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 31: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 32: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 33: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 34: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 35: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 36: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 37: org.armedbear.lisp.precompiler_73.execute(precompiler.lisp:643) 38: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 39: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 40: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 41: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 42: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 43: org.armedbear.lisp.precompiler_105.execute(precompiler.lisp:988) 44: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) 45: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 46: org.armedbear.lisp.compiler_pass2_362.execute(compiler-pass2.lisp:7380) 47: org.armedbear.lisp.Symbol.execute(Symbol.java:867) 48: org.armedbear.lisp.LispThread.execute(LispThread.java:918) 49: org.armedbear.lisp.compile_file_19.execute(compile-file.lisp:175) 50: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 51: org.armedbear.lisp.LispThread.execute(LispThread.java:832) 52: org.armedbear.lisp.compile_file_51.execute(compile-file.lisp:655) 53: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 54: org.armedbear.lisp.LispThread.execute(LispThread.java:851) 55: org.armedbear.lisp.compile_file_59.execute(compile-file.lisp:780) 56: org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) 57: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 58: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 59: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 60: org.armedbear.lisp.compile_file_57.execute(compile-file.lisp:780) 61: org.armedbear.lisp.Symbol.execute(Symbol.java:914) 62: org.armedbear.lisp.LispThread.execute(LispThread.java:986) 63: org.armedbear.lisp.compile_file_68.execute(compile-file.lisp:962) 64: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) 65: org.armedbear.lisp.Symbol.execute(Symbol.java:852) 66: org.armedbear.lisp.LispThread.execute(LispThread.java:894) 67: org.armedbear.lisp.Lisp.funcall(Lisp.java:180) 68: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) 69: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::KEY . CL-UTILS::FORMS)) 70: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::KEY . CL-UTILS::FORMS)) 71: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::LOOP CL-UTILS::FOR (CL-UTILS::KEY . CL-UTILS::FORMS) CL-UTILS::IN CL-UTILS::CLAUSES CL-UTILS::DO ...)) 72: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::LOOP CL-UTILS::FOR (CL-UTILS::KEY . CL-UTILS::FORMS) CL-UTILS::IN CL-UTILS::CLAUSES CL-UTILS::DO ...)) 73: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::LET ((CL-UTILS::CLAUSE-COLLECTION (CL-UTILS::LIST))) ..)) 74: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::LET ((CL-UTILS::CLAUSE-COLLECTION (CL-UTILS::LIST))) ..)) 75: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) ..)) 76: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) ..)) 77: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..)) 78: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..)) 79: (PRECOMPILER::PRECOMPILE-LAMBDA (LAMBDA NIL ..)) 80: (PRECOMPILER::PRECOMPILE1 (LAMBDA NIL (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) (CL-UTILS::LET # # #))))) 81: (JVM:COMPILE-DEFUN NIL (LAMBDA NIL (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) (CL-UTILS::LET # # #)))) NIL #P"/U.. 82: (SYSTEM::CONVERT-TOPLEVEL-FORM (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..) NIL) 83: (SYSTEM::PROCESS-TOPLEVEL-FORM (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..) #<FILE-STREAM {1773B7E}> NIL) 84: (JVM::%WITH-COMPILATION-UNIT #<LOCAL-FUNCTION IN COMPILE-FROM-STREAM {1FEBE62E}>) 85: (SYSTEM::COMPILE-FROM-STREAM #<FILE-STREAM {744E75DD}> #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-macosx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils-tmpUYPFRO0B.abcl" #P"/Users/lor.. 86: (COMPILE-FILE #P"/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils.lisp" :OUTPUT-FILE #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-macosx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils-tm.. 87: (APPLY COMPILE-FILE #P"/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils.lisp" :OUTPUT-FILE #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-macosx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-ut.. private static final void pushJavaStackFrames() { final LispThread thread = LispThread.currentThread(); final StackTraceElement[] frames = thread.getJavaStackTrace(); // frames[0] java.lang.Thread.getStackTrace // frames[1] org.armedbear.lisp.LispThread.getJavaStackTrace // frames[2] org.armedbear.lisp.Lisp.pushJavaStackFrames if (frames.length > 5 && frames[3].getClassName().equals("org.armedbear.lisp.Lisp") && frames[3].getMethodName().equals("error") && frames[4].getClassName().startsWith("org.armedbear.lisp.Lisp") && frames[4].getMethodName().equals("eval")) { // Error condition arising from within Lisp.eval(), so no // Java stack frames should be visible to the consumer of the stack abstraction return; } // Search for last Primitive in the StackTrace; that was the // last entry point from Lisp. int last = frames.length - 1; for (int i = 0; i<= last; i++) { if (frames[i].getClassName().startsWith("org.armedbear.lisp.Primitive")) last = i; } // Do not include the first three frames which, as noted above, constitute // the invocation of this method. while (last > 2) { thread.pushStackFrame(new JavaStackFrame(frames[last])); last--; } }

3 9

How to add abcl.jar to your class path for ABCL projects
by Mirko Vukovic 01 Jan '17

01 Jan '17

Hello, This is a follow-up to my earlier post on stack overflow. That problem is still not solved and here is one question. On the user documentation page I found the instruction to "add abcl.jar to your class path for ABCL projects" How do I do that? Thanks, Mirko

2 3

Re: stack overflow error on library load
by Alessio Stalla 20 Dec '16

20 Dec '16

Hmm, I wasn't actually expecting that :P maybe try updating SLIME... or perhaps this rings a bell for someone using ABCL on Windows regularly. Il 20 dic 2016 14:32, "Mirko Vukovic" <mirko.vukovic(a)gmail.com> ha scritto: > > > On Tue, Dec 20, 2016 at 8:25 AM Alessio Stalla <alessiostalla(a)gmail.com> > wrote: > >> You could try without SLIME, from the bare REPL. Not that SLIME breaks >> anything, but maybe you'll get a more understandable stack trace. >> > > Brilliant! Vecto loads in the Command Window (see below). What now? > > CL-USER(1): (asdf:load-system :vecto) > ; Compiling C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/package.lisp > ... > ; (DEFPACKAGE #:VECTO ...) > ; Wrote C:/Users/977315/AppData/Local/cache/common-lisp/abcl-1.4.0- > fasl42-win-x86/C/Users/977315/quicklisp/dists/quicklisp/ > software/vecto-1.4.10/package-tmpKHDC356G.abcl (0.036 seconds) > ; Compiling C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/utils.lisp > ... > ; (IN-PACKAGE #:VECTO) > ; (DEFUN CLAMP-RANGE ...) > ; (DEFUN FLOAT-OCTET ...) > ; (DEFUN OCTET-FLOAT ...) > ; (DEFVAR *HYPERDOC-BASE-URI* ...) > ; (LET (#) ...) > > >> >> On 20 December 2016 at 14:14, Mirko Vukovic <mirko.vukovic(a)gmail.com> >> wrote: >> >> >> >> On Tue, Dec 20, 2016 at 6:17 AM Alessio Stalla <alessiostalla(a)gmail.com> >> wrote: >> >> Could it be some path-related problem (e.g. spaces in the path, a very >> long path, unusual characters in the path, ...)? >> >> >> On my system the path to vecto is c:\Users\977314\quicklisp\... There >> are not spaces in the path. >> >> vecto depends on cl-vectors, zpng, zpb-ttf. I can load all of them >> without problem. >> >> Example of paths: >> >> ; SLIME 2.18 >> CL-USER> (asdf:system-source-directory :cl-vectors) >> #P"C:/Users/977315/quicklisp/dists/quicklisp/software/cl- >> vectors-20150407-git/" >> CL-USER> (asdf:system-source-directory :vecto) >> #P"C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/" >> CL-USER> >> >> If vecto.asd contains dependencies to those three libraries, the asd will >> load. Once I add a file to the list of components, it fails. >> >> Mirko >> >> >> >> On 18 December 2016 at 23:23, Mirko Vukovic <mirko.vukovic(a)gmail.com> >> wrote: >> >> Hello again, >> >> I have joined the mailing list, and also seen Mark Evenson's reply >> https://mailman.common-lisp.net/pipermail/armedbear-devel/ >> 2016-December/003759.html. >> It is encouraging that he can load Vecto. >> >> A few more details on my environment and more probing results >> >> Implementation details: >> >> CL-USER> (lisp-implementation-version) >> "1.4.0" >> "Java_HotSpot(TM)_Client_VM-Oracle_Corporation-1.7.0_51-b13" >> "x86-Windows_8-6.2" >> >> Does the above look OK? Version wise, it is close to what Mark has, >> except that he has >> JDK, and I have Java_HotSpot. >> >> ASDF Version: >> >> I was wondering if the issue had to do with ASDF's looking for libraries >> and files, i.e., whether >> I was hit by an ASDF bug. So I installed the latest ASDF moving from >> 3.1.7, to 3.1.7.43, >> (which is a release candidate for asdf 3.2) >> >> The stack overflow remains. >> >> Manual loading of dependencies (libraries and files): >> >> I verified that I can manually load all the libraries vecto depends on, >> and also manually >> compile and load all of its component files. >> >> Isolate bug by dividing up the ASDF file: >> >> To investigate further, I started commenting out parts of Vecto's asdf >> file. As long as the components >> list is empty, asdf will load Vecto. >> (asdf:defsystem #:vecto >> :depends-on (#:cl-vectors >> #:zpng >> #:zpb-ttf) >> :version "1.4.10" >> :author "Zach Beane <xach(a)xach.com>" >> :description "Create vector graphics in PNG files." >> :license "BSD" >> :components ()) >> >> But adding a file to the components list will cause stack overflow. For >> example >> this will cause stack overflow: >> >> (asdf:defsystem #:vecto >> :depends-on (#:cl-vectors >> #:zpng >> #:zpb-ttf) >> :version "1.4.10" >> :author "Zach Beane <xach(a)xach.com>" >> :description "Create vector graphics in PNG files." >> :license "BSD" >> :components ((:file "package"))) >> >> >> >> >> >> On Wed, Dec 14, 2016 at 8:54 AM Mirko Vukovic <mirko.vukovic(a)gmail.com> >> wrote: >> >> See below: >> >> On Tue, Dec 13, 2016 at 10:45 PM Mirko Vukovic <mirko.vukovic(a)gmail.com> >> wrote: >> >> Hello, >> >> I have installed ABCL 1.4 on Windows 10 and Java 1.7. >> >> When loading some libraries, I get a stack overflow error. >> >> For example loading vecto fails >> >> vecto passes the cl-test-grid on linux (see >> https://common-lisp.net/project/cl-test-grid/library/vecto.html) >> >> >> I did a bit more probing to try and isolate the cause of the overflow: >> >> - ASDF file manually loads and compiles >> - I could manually load all the pre-requisite libraries >> - I could manually compile and load all the lisp files >> >> Looking at the error message in frame 8 (see below), the cause may be >> in the slime/swank interaction with abcl. >> >> I may take this up at the slime mailing list. >> >> >> >> Running >> (asdf:load-system :vecto) >> >> Gives: >> Stack overflow. >> [Condition of type STORAGE-CONDITION] >> >> Restarts: >> 0: [*ABORT] Return to SLIME's top level. >> 1: [ABORT] Abort thread. >> >> Backtrace: >> 0: (#<FUNCTION {BEB670}> #<STORAGE-CONDITION {14AA1B6}> #<FUNCTION >> {BEB670}>) >> 1: (APPLY #<FUNCTION {BEB670}> (#<STORAGE-CONDITION {14AA1B6}> >> #<FUNCTION {BEB670}>)) >> 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION >> {14AA1B6}> #<FUNCTION {BEB670}>) >> 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {14AA1B6}>) >> 4: org.armedbear.lisp.Lisp.stackError(Lisp.java:388) >> 5: org.armedbear.lisp.swank_513.execute(swank.lisp:1677) >> 6: org.armedbear.lisp.LispThread.execute(LispThread.java:851) >> 7: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2800) >> 8: (SWANK:EVAL-FOR-EMACS (SWANK-REPL:LISTENER-EVAL "(asdf:load-system >> :vecto) >> ") "COMMON-LISP-USER" 9) >> etc >> >> >> >>

2 1

stack overflow error on library load
by Mirko Vukovic 20 Dec '16

20 Dec '16

Hello, I have installed ABCL 1.4 on Windows 10 and Java 1.7. When loading some libraries, I get a stack overflow error. For example loading vecto fails vecto passes the cl-test-grid on linux (see https://common-lisp.net/project/cl-test-grid/library/vecto.html) Running (asdf:load-system :vecto) Gives: Stack overflow. [Condition of type STORAGE-CONDITION] Restarts: 0: [*ABORT] Return to SLIME's top level. 1: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {BEB670}> #<STORAGE-CONDITION {14AA1B6}> #<FUNCTION {BEB670}>) 1: (APPLY #<FUNCTION {BEB670}> (#<STORAGE-CONDITION {14AA1B6}> #<FUNCTION {BEB670}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {14AA1B6}> #<FUNCTION {BEB670}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {14AA1B6}>) 4: org.armedbear.lisp.Lisp.stackError(Lisp.java:388) 5: org.armedbear.lisp.swank_513.execute(swank.lisp:1677) 6: org.armedbear.lisp.LispThread.execute(LispThread.java:851) 7: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2800) 8: (SWANK:EVAL-FOR-EMACS (SWANK-REPL:LISTENER-EVAL "(asdf:load-system :vecto) ") "COMMON-LISP-USER" 9) etc

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel December 2016