From: Alex M. <kil...@ne...> - 2007-03-13 14:38:37
|
Hello, All! i have problems with SLIME here (Windows, JDK 1.5.0, XEmacs, more-or-less recent ABCL and SLIME versions). when it loads first time (and compiles itself) it's quite ok. but on subsequent loads (when it loads compiled files) prompt appears and responds to commands, but when debugger is invoked, it crashes: ; Armed Bear Common Lisp Port: 2213 Pid: 0 CL-USER> (asfgs) Debugger invoked on condition of type ERROR: Unable to load #P"E:\\DOCUME Debugger invoked on condition of type ERROR: ... Debugger invoked on condition of type ERROR: Unable to load E:\DOCUME Maximum error depth exceeded (11 nested errors). CL-USER(2): i have to delete all FASL files to make it working, that's quite annoying. and also sometimes it doesn't load at all -- i see REPL, can issue commands in REPL, but emacs is unable to connect. i'll try to update SLIME and ABCL, and to indentify exact error if problem persists, but it would be nice if people using ABCL with Emacs/SLIME will confirm error or say that it works for them. (maybe i'm the only user of SLIME under Windows here?) i'm currently mostly use SLIME with ABCL loaded into Apache Tomcat, load sequence is bit different in this case, and there were (almost) no problems with it, but sometimes i'd like to load ABCL directly.. i've also checked older versions of ABCL -- at least this error is not introduced recently. but i remeber time when it was working :) With best regards, Alex Mizrahi. |
From: Alex M. <kil...@ne...> - 2007-03-13 14:44:52
|
(message (Hello 'Alex) (you :wrote :to '(All) :on '(Tue, 13 Mar 2007 16:37:53 +0200)) ( AM> ; Armed Bear Common Lisp Port: 2213 Pid: 0 AM> CL-USER> (asfgs) AM> Debugger invoked on condition of type ERROR: AM> Unable to load #P"E:\\DOCUME AM> Debugger invoked on condition of type ERROR: and as follow-up backtrace dump from *inferior-lisp* CL-USER(2): CL-USER(2): java.lang.VerifyError: (class: org/armedbear/lisp/abcl19446, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Inconsistent stack height 4 != 0 at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328) at java.lang.Class.getConstructor0(Class.java:2640) at java.lang.Class.getConstructor(Class.java:1629) at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1137) at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1064) at org.armedbear.lisp.CompiledFunction$1.execute(CompiledFunction.java:174) at org.armedbear.lisp.Symbol.execute(Symbol.java:708) at org.armedbear.lisp.jvm_1205.execute(jvm.lisp:10347) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:44) at org.armedbear.lisp.jvm_1202.execute(jvm.lisp:10301) at org.armedbear.lisp.CompiledFunction.execute(CompiledFunction.java:58) at org.armedbear.lisp.Symbol.execute(Symbol.java:708) at org.armedbear.lisp.jvm_1204.execute(jvm.lisp:10347) at org.armedbear.lisp.Symbol.execute(Symbol.java:721) at org.armedbear.lisp.jvm_1206.execute(jvm.lisp:10390) at org.armedbear.lisp.Symbol.execute(Symbol.java:721) at org.armedbear.lisp.jvm_1210.execute(jvm.lisp:10539) at org.armedbear.lisp.Symbol.execute(Symbol.java:721) at org.armedbear.lisp.LispThread.execute(LispThread.java:646) at org.armedbear.lisp.clos_125.execute(clos.lisp:1180) at org.armedbear.lisp.LispThread.execute(LispThread.java:625) that's weird, isn't it? :) IMHO this looks like a compiler producing incorrect byte code. ) (With-best-regards '(Alex Mizrahi) :aka 'killer_storm) "?? ???? ??????? ?????") |
From: Peter G. <pe...@ar...> - 2007-03-15 19:15:51
|
On Tue, 13 Mar 2007 at 16:44:18 +0200, Alex Mizrahi wrote: > (message (Hello 'Alex) > (you :wrote :to '(All) :on '(Tue, 13 Mar 2007 16:37:53 +0200)) > ( > > AM> ; Armed Bear Common Lisp Port: 2213 Pid: 0 > AM> CL-USER> (asfgs) > AM> Debugger invoked on condition of type ERROR: > AM> Unable to load #P"E:\\DOCUME > AM> Debugger invoked on condition of type ERROR: > > and as follow-up backtrace dump from *inferior-lisp* > > CL-USER(2): CL-USER(2): > java.lang.VerifyError: (class: org/armedbear/lisp/abcl19446, method: > execute signature: > (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) > Inconsistent stack height 4 != 0 > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328) > at java.lang.Class.getConstructor0(Class.java:2640) > at java.lang.Class.getConstructor(Class.java:1629) > at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1137) > at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1064) > at org.armedbear.lisp.CompiledFunction$1.execute(CompiledFunction.java:174) > at org.armedbear.lisp.Symbol.execute(Symbol.java:708) > at org.armedbear.lisp.jvm_1205.execute(jvm.lisp:10347) > at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:44) > at org.armedbear.lisp.jvm_1202.execute(jvm.lisp:10301) > at org.armedbear.lisp.CompiledFunction.execute(CompiledFunction.java:58) > at org.armedbear.lisp.Symbol.execute(Symbol.java:708) > at org.armedbear.lisp.jvm_1204.execute(jvm.lisp:10347) > at org.armedbear.lisp.Symbol.execute(Symbol.java:721) > at org.armedbear.lisp.jvm_1206.execute(jvm.lisp:10390) > at org.armedbear.lisp.Symbol.execute(Symbol.java:721) > at org.armedbear.lisp.jvm_1210.execute(jvm.lisp:10539) > at org.armedbear.lisp.Symbol.execute(Symbol.java:721) > at org.armedbear.lisp.LispThread.execute(LispThread.java:646) > at org.armedbear.lisp.clos_125.execute(clos.lisp:1180) > at org.armedbear.lisp.LispThread.execute(LispThread.java:625) > > that's weird, isn't it? :) > > IMHO this looks like a compiler producing incorrect byte code. Yes, this looks like a compiler bug. I can't do quite enough archaeology off this backtrace to pin down the exact problem, however. In this situation, there is probably a file with a name containing the string "abcl19446" (see the VerifyError above) left behind in a temporary directory somewhere. You can find that temporary directory by doing (EXT:MAKE-TEMP-FILE) at the repl and seeing what comes back. That file is the broken class file, and if you send it to me it might shed some additional light, although possibly not enough for a fix. I think what has probably happened is that some recent change in slime has run into an ABCL bug that was always there but was never triggered before, so another way to find the problem might be to identify the last version of slime that worked reliably and then look at what changed in the next commit. -Peter |
From: Alex M. <kil...@ne...> - 2007-03-16 09:03:29
|
(message (Hello 'Peter) (you :wrote :on '(Thu, 15 Mar 2007 12:15:42 -0700)) ( PG> doing (EXT:MAKE-TEMP-FILE) at the repl and seeing what comes back. That PG> file is the broken class file, and if you send it to me it might shed PG> some additional light, although possibly not enough for a fix. ok, i've send them PG> I think what has probably happened is that some recent change in slime PG> has run into an ABCL bug that was always there but was never triggered PG> before, so another way to find the problem might be to identify the PG> last version of slime that worked reliably and then look at what PG> changed in the next commit. ok, i'll try to find this version later, maybe. also, i think we can find what it tries to compile -- looks like these files are generated on-fly for each form in REPL or something like that.. that's weird. (at same time forms in REPL are not running compiled) ) (With-best-regards '(Alex Mizrahi) :aka 'killer_storm) "?? ???? ??????? ?????") |
From: Alex M. <kil...@ne...> - 2007-03-16 19:17:54
|
(message (Hello 'Alex) (you :wrote :to '(Peter Graves) :on '(Fri, 16 Mar 2007 11:03:10 +0200)) ( AM> also, i think we can find what it tries to compile -- looks like these AM> files are generated on-fly for each form in REPL or something like AM> that.. that's weird. (at same time forms in REPL are not running AM> compiled) i've found out to my surprise that it's CLOS compiles lambdas on fly (compile nil) a lot. it appears that it compiles something almost on each generic function call, so it goes for each action in SLIME, for each pieces of data that is sent to/from SLIME.. there are lot of stuff like this compiled: (LAMBDA (MOP::ARGS) (DECLARE (OPTIMIZE SPEED)) (FUNCALL #<FUNCTION (LAMBDA (MOP::ARGS MOP::NEXT-EMFUN)) {1BA18CE}> MOP::ARGS #<FUNCTION (LAMBDA (MOP::ARGS)) {B2BDE5}>)) VerifyError is cause by this expression: (LAMBDA (MOP::ARG) (DECLARE (OPTIMIZE SPEED)) (UNLESS (SYSTEM:SIMPLE-TYPEP MOP::ARG #<STANDARD-CLASS CLASS {4CEE32}>) (ERROR 'SIMPLE-TYPE-ERROR :DATUM MOP::ARG :EXPECTED-TYPE #<STANDARD-CLASS CLASS {4CEE32}>)) (FUNCALL #<FUNCTION (LAMBDA (CLASS)) {D49111}> MOP::ARG)) afaik ABCL's compiler is non-reentrant (not thread safe), so if CLOS actively uses it, it cannot work in multiple threads. so, this can explain CLOS multithreading bugs i've found long time ago, and they should be fixable by a simple mutex in compiler. (although current problem with SLIME is not caused by multiple threads -- i've tried to make that mutex for jvm-compile calls :). also, i sometimes experience CLOS being fantastically slow -- i didn't believe that code can run that slow :). but if in some cases CLOS compiles some lambda on each call, it can explain this behaviour.. ) (With-best-regards '(Alex Mizrahi) :aka 'killer_storm) "?? ???? ??????? ?????") |
From: Alex M. <kil...@ne...> - 2007-03-17 11:53:27
|
(message (Hello 'Alex) (you :wrote :to '(Alex Mizrahi) :on '(Fri, 16 Mar 2007 21:17:03 +0200)) ( AM> VerifyError is cause by this expression: AM> (LAMBDA (MOP::ARG) (DECLARE (OPTIMIZE SPEED)) (UNLESS AM> (SYSTEM:SIMPLE-TYPEP MOP::ARG #<STANDARD-CLASS CLASS {4CEE32}>) (ERROR AM> 'SIMPLE-TYPE-ERROR :DATUM MOP::ARG :EXPECTED-TYPE #<STANDARD-CLASS CLASS AM> {4CEE32}>)) (FUNCALL #<FUNCTION (LAMBDA (CLASS)) {D49111}> MOP::ARG)) i've advanced step further into analysis of this mystical fail. analysis of stack trace shows us that this happens during %PRINT-UNREADABLE-OBJECT -- so, during printing of some object. of question is type of this object. so i printed all types of objects that come to %PRINT-UNREADABLE-OBJECT. it appears that it crashes near printing condition of type UNDEFINED-FUNCTION. so i guess that's PRINT-OBJECT generic function tries to compile something to call method (defmethod print-object ((x undefined-function) stream) so i've tried to invoke this function with simple (make-condition 'undefined-function) to get it printed in REPL. and indeed, printing it in REPL fixes the thing -- SLIME works find if i print some UNDEFINED-FUNCTION in REPL first. ABCL is able to compile discriminating function (efective method, or what a hell does CLOS try to compile) normally, but when it tries to compile it when called by SLIME debugger it crashes.. so for next step i'll try to analyze what on this call stack affects compiler a way it produces wrong code.. it's also interesting why first run is different from subsequent ones. most likely that it's because in first run it compiles code, and calls that PRINT-OBJECT, so CLOS compiles it's functions beforehands. ) (With-best-regards '(Alex Mizrahi) :aka 'killer_storm) "?? ???? ??????? ?????") |
From: Peter G. <pe...@ar...> - 2007-03-17 15:07:20
|
On Sat, 17 Mar 2007 at 13:53:04 +0200, Alex Mizrahi wrote: > ABCL is able to compile discriminating function (efective method, or what a > hell does CLOS try to compile) normally, but when it tries to compile it > when called by SLIME debugger it crashes.. > so for next step i'll try to analyze what on this call stack affects > compiler a way it produces wrong code.. > > it's also interesting why first run is different from subsequent ones. most > likely that it's because in first run it compiles code, and calls that > PRINT-OBJECT, so CLOS compiles it's functions beforehands. The code being compiled in the case you're talking about is the lambda form at line 1226 of clos.lisp. The brokenness is very strange: the call to ERROR is being miscompiled, with the wrong signature for the invokevirtual call, so that it consumes only 1 of its 5 arguments, thus leading to the stack imbalance. Compiling the same lambda form from the repl works fine. My current working hypothesis is that in the broken case, slime is somehow using the compiler in a situation where it (or possibly CLOS) is not properly initialized (although even so, I still can't imagine anything that would cause the specific breakage I'm seeing). Your (make-condition 'undefined-function) trick most likely works because it's forcing the required infrastructure to be autoloaded, in the same way that things work correctly when slime has to compile all of its files first on startup. (Yes, autoloading is most likely the root of all this evil.) -Peter |
From: Peter G. <pe...@ar...> - 2007-03-17 18:44:18
|
On Sat, 17 Mar 2007 at 08:07:13 -0700, Peter Graves wrote: > My current working hypothesis is that in the broken case, slime is > somehow using the compiler in a situation where it (or possibly CLOS) > is not properly initialized (although even so, I still can't imagine > anything that would cause the specific breakage I'm seeing). It turns out that there was no problem with the initialization of CLOS or the compiler, but slime was fiddling with *print-foo* specials and JVM::MAKE-DESCRIPTOR-INFO needed a WITH-STANDARD-IO-SYNTAX wrapper. Fixed in CVS. Thanks for your help with this! -Peter |
From: Andras S. <as...@ma...> - 2007-03-17 21:01:28
|
On Sat, 17 Mar 2007, Peter Graves wrote: > On Sat, 17 Mar 2007 at 08:07:13 -0700, Peter Graves wrote: >> My current working hypothesis is that in the broken case, slime is >> somehow using the compiler in a situation where it (or possibly CLOS) >> is not properly initialized (although even so, I still can't imagine >> anything that would cause the specific breakage I'm seeing). > > It turns out that there was no problem with the initialization of CLOS > or the compiler, but slime was fiddling with *print-foo* specials and > JVM::MAKE-DESCRIPTOR-INFO needed a WITH-STANDARD-IO-SYNTAX wrapper. > > Fixed in CVS. Thanks to both you and Alex for sorting this out! Andras |
From: Andras S. <as...@ma...> - 2007-03-13 15:43:12
|
On Tue, 13 Mar 2007, Alex Mizrahi wrote: > Hello, All! > > i have problems with SLIME here (Windows, JDK 1.5.0, XEmacs, more-or-less > recent ABCL and SLIME versions). > > when it loads first time (and compiles itself) it's quite ok. > > but on subsequent loads (when it loads compiled files) prompt appears and > responds to commands, but when debugger is invoked, it crashes: > > ; Armed Bear Common Lisp Port: 2213 Pid: 0 > CL-USER> (asfgs) > Debugger invoked on condition of type ERROR: > Unable to load #P"E:\\DOCUME > Debugger invoked on condition of type ERROR: > > ... > > Debugger invoked on condition of type ERROR: > Unable to load E:\DOCUME > Maximum error depth exceeded (11 nested errors). > CL-USER(2): > > i have to delete all FASL files to make it working, that's quite annoying. > and also sometimes it doesn't load at all -- i see REPL, can issue commands > in REPL, but emacs is unable to connect. > > i'll try to update SLIME and ABCL, and to indentify exact error if problem > persists, > but it would be nice if people using ABCL with Emacs/SLIME will confirm > error or say that it works for them. (maybe i'm the only user of SLIME under > Windows here?) I can confirm this. I don't get the error you quote here, but I do see the Java backtrace you sent in your other mail. I tried to narrow this down to something bug-reportable, but failed miserably. Andras |