Hi,
This (a call in my LSW system) used to work for me and is now failing in trunk. However I don't seem to have anything to go on in the stack trace. Any suggestions?
Thanks, Alan
CL-USER(2): (load-ontology "~/repos/obi/ontology/obi.owl") #<THREAD "interpreter" {FE90EF}>: Debugger invoked on condition of type STORAGE-CONDITION Stack overflow. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :bt 0: (SYSTEM:BACKTRACE) 1: (APPLY #<FUNCTION SYSTEM:BACKTRACE {55C752}> NIL) 2: (SYSTEM:BACKTRACE) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {1985DA}>) 4: org.armedbear.lisp.Lisp$1.execute(Lisp.java:288) 5: org.armedbear.lisp.Symbol.execute(Symbol.java:776) 6: org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92)
Hi Alan,
On Tue, Apr 27, 2010 at 4:31 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Hi,
This (a call in my LSW system) used to work for me and is now failing in trunk. However I don't seem to have anything to go on in the stack trace. Any suggestions?
Right. What you're seeing is expected: the stack gets unwound before raising this error, because there's no room left on the stack to actually handle it. It's a bit unfortunate.
What I do to work on stuff like this is to make sure I get visual feedback (printf) to see where in the file the error might occur. I'm not sure if I can come up with anything else.
Bye,
Erik.
On Tue, Apr 27, 2010 at 2:40 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Alan,
On Tue, Apr 27, 2010 at 4:31 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Hi,
This (a call in my LSW system) used to work for me and is now failing in trunk. However I don't seem to have anything to go on in the stack trace. Any suggestions?
Right. What you're seeing is expected: the stack gets unwound before raising this error, because there's no room left on the stack to actually handle it. It's a bit unfortunate.
Any chance of writing the stack to a file before tossing it? Is there a way of signaling the stack condition when there's still some stack left - is that a knob that Java offers?
What I do to work on stuff like this is to make sure I get visual feedback (printf) to see where in the file the error might occur. I'm not sure if I can come up with anything else.
So I've tried to do that, but it looks like it's in or around a call to a java function. I can try to dissect it more by printing inside my jss code.
Bleh.
-Alan
Bye,
Erik.
On Tue, Apr 27, 2010 at 9:37 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Any chance of writing the stack to a file before tossing it? Is there a way of signaling the stack condition when there's still some stack left - is that a knob that Java offers?
Actually the stack trace should be saved as the value of ext:*saved-backtrace* just before signaling the condition.
On Tue, Apr 27, 2010 at 3:51 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Tue, Apr 27, 2010 at 9:37 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Any chance of writing the stack to a file before tossing it? Is there a way of signaling the stack condition when there's still some stack left - is that a knob that Java offers?
Actually the stack trace should be saved as the value of ext:*saved-backtrace* just before signaling the condition.
hm.. (setq kb (load-ontology "/Users/alanr/obi/ontology/obi.owl")) ; Evaluation aborted. CL-USER> ext:*saved-backtrace* NIL
-Alan
On Wed, Apr 28, 2010 at 4:16 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Tue, Apr 27, 2010 at 3:51 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Tue, Apr 27, 2010 at 9:37 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Any chance of writing the stack to a file before tossing it? Is there a way of signaling the stack condition when there's still some stack left - is that a knob that Java offers?
Actually the stack trace should be saved as the value of ext:*saved-backtrace* just before signaling the condition.
hm.. (setq kb (load-ontology "/Users/alanr/obi/ontology/obi.owl")) ; Evaluation aborted. CL-USER> ext:*saved-backtrace* NIL
Wait - that's in slime. Outside slime there's more. Looking now...
-Alan
-Alan
This is what stack overflows:
(pathname-host "file:///Users/alanr/repos/obi/trunk/src/ontology/branches/obi.owl")
-Alan
On Wed, Apr 28, 2010 at 10:39 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
This is what stack overflows:
(pathname-host "file:///Users/alanr/repos/obi/trunk/src/ontology/branches/obi.owl")
I can reproduce it: the Pathname(String) constructor apparently goes on infinite recursion with file: urls.
Alessio
On 4/29/10 8:25 PM, Alessio Stalla wrote:
On Wed, Apr 28, 2010 at 10:39 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
This is what stack overflows:
(pathname-host "file:///Users/alanr/repos/obi/trunk/src/ontology/branches/obi.owl")
I can reproduce it: the Pathname(String) constructor apparently goes on infinite recursion with file: urls.
This should be fixed with [r12641][1]. Thanks for the report.
[1]: http://trac.common-lisp.net/armedbear/changeset/12641
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Alessio Stalla -
Erik Huelsmann -
Mark Evenson