From: Pascal C. <pc...@p-...> - 2005-01-31 21:07:28
|
Hi, I am currently working on a MOP compatibility library - see http://common-lisp.net/project/closer/ The first step of that project is to provide a suite that checks what features are available in a given CLOS implementation and what features are missing. However, I haven't yet been able to make the suite run in one go, which would be important in the long run. (Each test works when run in isolation.) The problem occurs both in SBCL 0.8.19 (on Mac OS X) and CMU CL (Pierre Mai's experimental port to Mac OS X). What happens is this: A few test execute successfully, and at some stage I get the following message in SBCL. >>> Control stack guard page temporarily disabled: proceed with caution debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread 5201: Control stack exhausted (no more space for function call frames). This is probably due to heavily nested or infinitely recursive function calls, or a tail call that SBCL cannot or has not optimized away. You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). 1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. <<< Afterwards, SBCL hangs, doesn't respond to keystrokes anymore, and I can only kill the respective process. CMU CL just hangs, without a message, but exactly at the same points in the test suite. This is repeatable. For example, when I run the tests one by one in some other order, the same bug occurs again at the same point for that order in both implementations. Do you think there is a chance that I can get the suite to run? (The code can be downloaded from the link above...) For example, do you think it makes sense to try this on an Intel-based platform? Any help is appreciated. Pascal P.S.: I haven sent this email both to sbcl-devel and cmucl-imp. -- Any sufficently complicated Java program requires a programmable IDE to make up for the half of Common Lisp not implemented in the program itself. - Peter Seibel |
From: Dimitry G. <di...@gm...> - 2005-02-01 16:25:23
|
I tried running it on sbcl 0.18.18 x86 and got the following error: This MOP implementations misses the features :validate-superclass, :standard-writer-method, :standard-reader-method, :standard-object, :standard-method, :standard-generic-function, :standard-effective-slot-definition, :standard-direct-slot-definition, :standard-class, :specializer-direct-methods, :slot-makunbound-using-class, :slot-definition-writers, :slot-definition-type, :slot-definition-readers, :slot-definition-name, :slot-definition-location, :slot-definition-initfunction, :slot-definition-initform, :slot-definition-initargs, :slot-definition-allocation, :slot-boundp-using-class, :setf-slot-value-using-class, :method-specializers, :method-lambda-list, :method-generic-function, :method-function, :method-combination, :method, :metaobject, :generic-function-name, :generic-function-methods, :generic-function-method-combination, :generic-function-method-class, :generic-function-lambda-list, :generic-function-initialized-with-name, :generic-function-initialized-with-method-combination, :generic-function-initialized-with-lambda-list, :generic-function-initialized-with-documentation, :generic-function-initialized-with-argument-precedence-order, :generic-function-declarations, :generic-function-argument-precedence-order, :generic-function, :funcallable-standard-class, :forward-referenced-class, :finalize-inheritance, :extract-specializer-names, :extract-lambda-list, :ensure-generic-function-using-class, :ensure-class-using-class, :effective-slot-definition-initialized-with-type, :effective-slot-definition-initialized-with-name, :effective-slot-definition-initialized-with-initfunction, :effective-slot-definition-initialized-with-initform, :effective-slot-definition-initialized-with-initargs, :effective-slot-definition-initialized-with-documentation, :direct-slot-definition-initialized-with-writers, :direct-slot-definition-initialized-with-type, :direct-slot-definition-initialized-with-readers, :direct-slot-definition-initialized-with-name, :direct-slot-definition-initialized-with-initfunction, :direct-slot-definition-initialized-with-initform, :direct-slot-definition-initialized-with-initargs, :direct-slot-definition-initialized-with-documentation, :direct-slot-definition-initialized-with-allocation, :direct-slot-definition-class, :defclass-calls-reinitialize-instance, :defclass-calls-initialize-instance, :compute-class-precedence-list, :class-prototype, :class-precedence-list, :class-initialized-with-name, :class-initialized-with-documentation, :class-initialized-with-direct-superclasses, :class-initialized-with-direct-slots, :class-finalized-p, :class-direct-superclasses, :class-direct-subclasses, :class-direct-slots, :class-direct-default-initargs, :class-default-initargs, :class, :built-in-class, :add-direct-subclass whose potential absence I don't know about. [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Retry assertion. 1: [ABORT] Abort handling SLIME request. 2: [DESTROY-THREAD] Destroy this thread (1602) Backtrace: 0: (SB-KERNEL:ASSERT-ERROR 5 (NULL MOP-FEATURE-TESTS::UNKNOWN-MISSING-FEATURES) NIL "This MOP implementations misses the feature~P ~(~{~:_~S~^, ~}~) whose potential absence I don't know about.")[:EXTERNAL] 1: ("varargs entry for MOP-FEATURE-TESTS:CHECK-FEATURES") 2: (SB-INT:EVAL-IN-LEXENV 2 (MOP-FEATURE-TESTS:CHECK-FEATURES) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] 3: ("hairy arg processor for SWANK::EVAL-REGION" "(mop-feature-tests:check-features) " T) 4: ("#'(LAMBDA NIL (MULTIPLE-VALUE-BIND # # ...))") Dimitry On Mon, 31 Jan 2005 22:07:18 +0100, Pascal Costanza <pc...@p-...> wrote: > Hi, > > I am currently working on a MOP compatibility library - see > http://common-lisp.net/project/closer/ > > The first step of that project is to provide a suite that checks what > features are available in a given CLOS implementation and what features > are missing. However, I haven't yet been able to make the suite run in > one go, which would be important in the long run. (Each test works when > run in isolation.) > > The problem occurs both in SBCL 0.8.19 (on Mac OS X) and CMU CL (Pierre > Mai's experimental port to Mac OS X). > > What happens is this: A few test execute successfully, and at some > stage I get the following message in SBCL. > > >>> > > Control stack guard page temporarily disabled: proceed with caution > > debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread 5201: > Control stack exhausted (no more space for function call frames). > This is probably due to heavily nested or infinitely recursive function > calls, or a tail call that SBCL cannot or has not optimized away. > > You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [ABORT ] Reduce debugger level (leaving debugger, returning to > toplevel). > 1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. > > <<< > > Afterwards, SBCL hangs, doesn't respond to keystrokes anymore, and I > can only kill the respective process. CMU CL just hangs, without a > message, but exactly at the same points in the test suite. This is > repeatable. For example, when I run the tests one by one in some other > order, the same bug occurs again at the same point for that order in > both implementations. > > Do you think there is a chance that I can get the suite to run? (The > code can be downloaded from the link above...) > > For example, do you think it makes sense to try this on an Intel-based > platform? > > Any help is appreciated. > > Pascal > > P.S.: I haven sent this email both to sbcl-devel and cmucl-imp. > > -- > Any sufficently complicated Java program requires a programmable IDE to > make up for the half of Common Lisp not implemented in the program > itself. - Peter Seibel > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Pascal C. <pc...@p-...> - 2005-02-01 16:52:45
|
On 1 Feb 2005, at 17:24, Dimitry Gashinsky wrote: > I tried running it on sbcl 0.18.18 x86 and got the following error: [...] Thanks, but the resulting output means: a) The error message is part of the diagnosis of the test results, so this seems to be ok basically. b) However, the MOP doesn't seem to implement any feature, so the suite probably just doesn't find the tests that it should run (and therefore cannot trigger the actual bug). Did you set *mop-feature-test-path*? Pascal -- The big bang way only works for god, everybody else has to use evolution. - David Moon |
From: Dimitry G. <di...@gm...> - 2005-02-01 17:24:50
|
Got the same error and got stock as you reported: :COMPUTE-DEFAULT-INITARGS ; loading #P"/home/dig/src/lisp/mop-features/tests/compute-discriminating-function.lisp" Control stack guard page temporarily disabled: proceed with caution Dimitry On Tue, 1 Feb 2005 17:52:33 +0100, Pascal Costanza <pc...@p-...> wrote: > > On 1 Feb 2005, at 17:24, Dimitry Gashinsky wrote: > > > I tried running it on sbcl 0.18.18 x86 and got the following error: > [...] > > Thanks, but the resulting output means: > a) The error message is part of the diagnosis of the test results, so > this seems to be ok basically. > b) However, the MOP doesn't seem to implement any feature, so the suite > probably just doesn't find the tests that it should run (and therefore > cannot trigger the actual bug). Did you set *mop-feature-test-path*? > > Pascal > > -- > The big bang way only works for god, everybody else has to use > evolution. - David Moon > > |
From: Pascal C. <pc...@p-...> - 2005-02-01 17:35:53
|
OK thanks. This means it's a platform-independent bug. Pascal On 1 Feb 2005, at 18:24, Dimitry Gashinsky wrote: > Got the same error and got stock as you reported: > > :COMPUTE-DEFAULT-INITARGS > ; loading > #P"/home/dig/src/lisp/mop-features/tests/compute-discriminating- > function.lisp" > Control stack guard page temporarily disabled: proceed with caution > > Dimitry > > On Tue, 1 Feb 2005 17:52:33 +0100, Pascal Costanza <pc...@p-...> > wrote: >> >> On 1 Feb 2005, at 17:24, Dimitry Gashinsky wrote: >> >>> I tried running it on sbcl 0.18.18 x86 and got the following error: >> [...] >> >> Thanks, but the resulting output means: >> a) The error message is part of the diagnosis of the test results, so >> this seems to be ok basically. >> b) However, the MOP doesn't seem to implement any feature, so the >> suite >> probably just doesn't find the tests that it should run (and therefore >> cannot trigger the actual bug). Did you set *mop-feature-test-path*? >> >> Pascal >> >> -- >> The big bang way only works for god, everybody else has to use >> evolution. - David Moon >> >> > > -- But do not try and hide the parens. That's impossible. Instead only try to realize the truth. There are no parens. - Tayssir John Gabbour |
From: Pascal C. <pc...@p-...> - 2005-02-01 19:48:30
|
On 31 Jan 2005, at 22:07, Pascal Costanza wrote: > Hi, > > I am currently working on a MOP compatibility library - see > http://common-lisp.net/project/closer/ > > The first step of that project is to provide a suite that checks what > features are available in a given CLOS implementation and what > features are missing. However, I haven't yet been able to make the > suite run in one go, which would be important in the long run. (Each > test works when run in isolation.) > > The problem occurs both in SBCL 0.8.19 (on Mac OS X) and CMU CL > (Pierre Mai's experimental port to Mac OS X). I have found a more specific case. Try this: (use-package :sb-mop) (loop for i from 1 do (let ((class-name (gensym))) (print i) (eval `(progn (defclass ,class-name (standard-generic-function) () (:metaclass funcallable-standard-class)) (defmethod compute-discriminating-function :after ((function ,class-name)) (print 'hi)) (defgeneric ,(gensym) () (:generic-function-class ,class-name)))))) This code doesn't make SBCL hang, but it triggers a stack exhaustion. Pascal -- So the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well. - Jerome Simeon and Philip Wadler |