From: James Y K. <fo...@fu...> - 2006-07-20 19:15:10
|
I've started getting this error after upgrading sbcl. It occurs after compiling & loading a bunch of our system. It seems to happen during the loading of (defmethod print-object ...) from a fasl. But only once -- retrying loading the fasl *succeeds*. It is happening with 0.9.14.22 and .27, but not 0.9.12.26. I recompiled the function find-free-cache-line w/o optimization in order to track down where the error was coming from, so the below backtrace shows the sub-functions that would normally be inlined there. But at this point I basically have no real idea what's causing it, other than that find-free-cache-line probably shouldn't be getting a primary of -1. Ring a bell for anyone? James The value -3 is not of type (MOD 536870911). 0: ((LAMBDA (SB-IMPL::E)) #<TYPE-ERROR {5C890731}>) 1: ((LAMBDA (SB-IMPL::E)) #<TYPE-ERROR {5C890731}>) 2: (SIGNAL #<TYPE-ERROR {5C890731}>) 3: (ERROR TYPE-ERROR) 4: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XF7A14EE4) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XF7A14A38 :TYPE (* (SB- ALIEN:STRUCT SB- VM::OS-CONTEXT-T-STRUCT))> (13 78)) 5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XF7A14A38) #<unavailable argument>) 6: ("foreign function: call_into_lisp") 7: ("foreign function: funcall2") 8: ("foreign function: interrupt_internal_error") 9: ("foreign function: sigtrap_handler") 10: ("foreign function: #xDD21C") 11: ((LABELS SB-PCL::LOCATION-VALID-P) -3 (#<SB-PCL::WRAPPER #<STANDARD-CLASS QRES-CORE::EDIFACT-OUTPUT- SIMPLE-ELEMENT> {57702FC1}> #<SB-KERNEL:LAYOUT for T {56061531}>)) 12: ((LABELS SB-PCL::LINE-VALID-P) -1 (#<SB-PCL::WRAPPER #<STANDARD-CLASS QRES-CORE::EDIFACT-OUTPUT- SIMPLE-ELEMENT> {57702FC1}> #<SB-KERNEL:LAYOUT for T {56061531}>)) 13: (SB-PCL::FIND-FREE-CACHE-LINE -1 #<SB-PCL::CACHE 2 T 8 {5C866639}> (#<SB-PCL::WRAPPER #<STANDARD-CLASS QRES-CORE::EDIFACT-OUTPUT- SIMPLE-ELEMENT> {57702FC1}> #<SB-KERNEL:LAYOUT for T {56061531}>)) 14: (SB-PCL::FILL-CACHE-P NIL #<SB-PCL::CACHE 2 T 8 {5C866639}> (#<SB-PCL::WRAPPER #<STANDARD-CLASS QRES-CORE::EDIFACT-OUTPUT- SIMPLE-ELEMENT> {57702FC1}> #<SB-KERNEL:LAYOUT for T {56061531}>) #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) :ARG-INFO (2))) 15: (SB-PCL::FILL-CACHE #<SB-PCL::CACHE 2 T 8 {5C866639}> (#<SB-PCL::WRAPPER #<STANDARD-CLASS QRES-CORE::EDIFACT-OUTPUT- SIMPLE-ELEMENT> {57702FC1}> #<SB-KERNEL:LAYOUT for T {56061531}>) #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) :ARG-INFO (2))) 16: ((FLET SB-PCL::ADD-CLASS-LIST) (#<STANDARD-CLASS QRES-CORE::EDIFACT-OUTPUT-SIMPLE-ELEMENT> #<BUILT-IN-CLASS T>)) 17: (SB-PCL::MAKE-EMF-CACHE #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (252)> T #<unavailable argument> NIL NIL) 18: (SB-PCL::MAKE-FINAL-CACHING-DFUN #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (252)> NIL NIL) 19: (SB-PCL::MAKE-FINAL-DFUN-INTERNAL #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (252)> NIL) 20: (SB-PCL::MAKE-FINAL-DFUN #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (252)> NIL) 21: (SB-PCL::UPDATE-DFUN #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (252)> NIL NIL NIL) 22: ((SB-PCL::FAST-METHOD REINITIALIZE-INSTANCE :AROUND (STANDARD-GENERIC-FUNCTION)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (252)> NIL) 23: (SB-PCL::REAL-ENSURE-GF-USING-CLASS--GENERIC-FUNCTION #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (252)> PRINT-OBJECT #<unavailable &REST argument> :ENVIRONMENT NIL :LAMBDA-LIST NIL :GENERIC-FUNCTION-CLASS STANDARD-GENERIC-FUNCTION) 24: (SB-PCL::REAL-ADD-NAMED-METHOD PRINT-OBJECT NIL (STREAMER-ERROR T) (OBJECT STREAM) :DEFINITION-SOURCE #S(SB-C:DEFINITION-SOURCE-LOCATION :NAMESTRING "[...].lisp" :TOPLEVEL-FORM-NUMBER 3 :PLIST NIL) :METHOD-SPEC (SB-PCL::SLOW-METHOD PRINT-OBJECT (STREAMER-ERROR T)) :FAST-FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD PRINT-OBJECT #) {5C84CCA5}> :PLIST (:ARG-INFO (2))) 25: (SB-PCL::LOAD-DEFMETHOD-INTERNAL STANDARD-METHOD PRINT-OBJECT NIL (STREAMER-ERROR T) (OBJECT STREAM) #<unavailable argument> NIL #S(SB-C:DEFINITION-SOURCE-LOCATION :NAMESTRING "[...].lisp" :TOPLEVEL-FORM-NUMBER 3 :PLIST NIL)) 26: (SB-FASL::LOAD-FASL-GROUP #<SB-SYS:FD-STREAM for "file [...].fasl" {5C8317E1}>) [[[rest of backtrace snipped]]] |
From: Christophe R. <cs...@ca...> - 2006-07-20 20:13:31
|
James Y Knight <fo...@fu...> writes: > I've started getting this error after upgrading sbcl. It occurs after > compiling & loading a bunch of our system. It seems to happen during > the loading of (defmethod print-object ...) from a fasl. But only > once -- retrying loading the fasl *succeeds*. It is happening with > 0.9.14.22 and .27, but not 0.9.12.26. > > I recompiled the function find-free-cache-line w/o optimization in > order to track down where the error was coming from, so the below > backtrace shows the sub-functions that would normally be inlined > there. But at this point I basically have no real idea what's causing > it, other than that find-free-cache-line probably shouldn't be > getting a primary of -1. Ring a bell for anyone? Yes, me. Darn. This is a symptom of an invalid wrapper (from a class which has since been redefined or finalized) getting into the cache system, which uses wrappers to index effective methods; this is now happening because the rearrangement to support anonymous classes leaves classes unfinalized for longer. (I fixed several codepaths where I got this error message, but apparently one remains: if you can reduce your test case at all, that would be very helpful.) > 14: (SB-PCL::FILL-CACHE-P > NIL > #<SB-PCL::CACHE 2 T 8 {5C866639}> > (#<SB-PCL::WRAPPER #<STANDARD-CLASS QRES-CORE::EDIFACT-OUTPUT- > SIMPLE-ELEMENT> {57702FC1}> > #<SB-KERNEL:LAYOUT for T {56061531}>) > #S(SB-PCL::FAST-METHOD-CALL > :FUNCTION #<FUNCTION #> > :PV-CELL NIL > :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL > :FUNCTION # > :PV-CELL NIL > :NEXT-METHOD-CALL NIL > :ARG-INFO (2)) > :ARG-INFO (2))) > 15: (SB-PCL::FILL-CACHE > #<SB-PCL::CACHE 2 T 8 {5C866639}> > (#<SB-PCL::WRAPPER #<STANDARD-CLASS QRES-CORE::EDIFACT-OUTPUT- > SIMPLE-ELEMENT> {57702FC1}> > #<SB-KERNEL:LAYOUT for T {56061531}>) > #S(SB-PCL::FAST-METHOD-CALL > :FUNCTION #<FUNCTION #> > :PV-CELL NIL > :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL > :FUNCTION # > :PV-CELL NIL > :NEXT-METHOD-CALL NIL > :ARG-INFO (2)) > :ARG-INFO (2))) > 16: ((FLET SB-PCL::ADD-CLASS-LIST) > (#<STANDARD-CLASS QRES-CORE::EDIFACT-OUTPUT-SIMPLE-ELEMENT> > #<BUILT-IN-CLASS T>)) > 17: (SB-PCL::MAKE-EMF-CACHE > #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (252)> > T > #<unavailable argument> > NIL > NIL) > 18: (SB-PCL::MAKE-FINAL-CACHING-DFUN > #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (252)> > NIL > NIL) Somewhere in here, the class-wrapper for EDIFACT-OUTPUT-SIMPLE-ELEMENT has been invalidated (by a call to UPDATE-CLASS or FINALIZE-INHERITANCE, I think). However, something is using that invalid wrapper; you can see in MAKE-EMF-CACHE as it currently stands that I wrote some code to refetch the wrappers from the classes, but apparently this is not enough. Cheers, Christophe |
From: James Y K. <fo...@fu...> - 2006-07-21 14:40:06
|
On Jul 20, 2006, at 4:13 PM, Christophe Rhodes wrote: > Yes, me. Darn. This is a symptom of an invalid wrapper (from a class > which has since been redefined or finalized) getting into the cache > system, which uses wrappers to index effective methods; this is now > happening because the rearrangement to support anonymous classes > leaves classes unfinalized for longer. (I fixed several codepaths > where I got this error message, but apparently one remains: if you can > reduce your test case at all, that would be very helpful.) I have so far been completely unable to. Attempts to isolate the issue has only resulted in it going away. I cannot see anything particularly interesting about that particular class definition, either, that would make it cause an error when others do not. I tried to trace invalidate-wrapper to see where the class wrapper for that class got invalidated, but it doesn't appear to have been. Inspecting the object shows it clearly is invalid, though. Might it have started invalid? James |
From: Christophe R. <cs...@ca...> - 2006-07-21 14:51:08
|
James Y Knight <fo...@fu...> writes: > On Jul 20, 2006, at 4:13 PM, Christophe Rhodes wrote: >> Yes, me. Darn. This is a symptom of an invalid wrapper (from a class >> which has since been redefined or finalized) getting into the cache >> system, which uses wrappers to index effective methods; this is now >> happening because the rearrangement to support anonymous classes >> leaves classes unfinalized for longer. (I fixed several codepaths >> where I got this error message, but apparently one remains: if you can >> reduce your test case at all, that would be very helpful.) > > I have so far been completely unable to. Attempts to isolate the > issue has only resulted in it going away. I cannot see anything > particularly interesting about that particular class definition, > either, that would make it cause an error when others do not. > > I tried to trace invalidate-wrapper to see where the class wrapper > for that class got invalidated, but it doesn't appear to have been. > Inspecting the object shows it clearly is invalid, though. Might it > have started invalid? No. On the other hand, invalidate-wrapper is not the only way wrappers get invalidated; another way is when a superclass's wrapper is invalidated from register-layout, calling invalidate-layout. That might be worth pursuing... Cheers, Christophe |
From: James Y K. <fo...@fu...> - 2006-07-24 20:31:08
|
On Jul 21, 2006, at 10:39 AM, James Y Knight wrote: > On Jul 20, 2006, at 4:13 PM, Christophe Rhodes wrote: >> Yes, me. Darn. This is a symptom of an invalid wrapper (from a >> class >> which has since been redefined or finalized) getting into the cache >> system, which uses wrappers to index effective methods; this is now >> happening because the rearrangement to support anonymous classes >> leaves classes unfinalized for longer. (I fixed several codepaths >> where I got this error message, but apparently one remains: if you >> can >> reduce your test case at all, that would be very helpful.) > > I have so far been completely unable to. Attempts to isolate the > issue has only resulted in it going away. I cannot see anything > particularly interesting about that particular class definition, > either, that would make it cause an error when others do not. > > I tried to trace invalidate-wrapper to see where the class wrapper > for that class got invalidated, but it doesn't appear to have been. > Inspecting the object shows it clearly is invalid, though. Might it > have started invalid? We've managed to narrow down the file causing the error to the following small snippet. HOWEVER, this code doesn't actually cause an issue standing alone (even with the base classes defined/etc). Only after loading the rest of our system, does this code crash. Is there anything useful I could look at the time this file starts being compiled to determine what could be corrupted and causing this? It seems like some subtle corruption... (defclass FOO () ()) (defmethod print-object ((m FOO) stream) nil) (eval-when (:compile-toplevel :load-toplevel :execute) (defclass edifact-output-element (base-edifact-segment) ()) (defclass edifact-output-simple-element (edifact-output-element) ((name :accessor edifact-element-name))) ) As far as I can tell, all elements in this example are required. Note that while removing the eval-when from (the original form of) this file causes _this file_ to be compiled & loaded successfully, the same error occurs later in the compilation process when defining another print-object specializer. WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL {58C2DBD9}> on #<CL-SOURCE-FILE "edifact-generation" {5A139499}>. debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {5768A751}>: Error during processing of --eval option (LOAD #P"./make-prep/make- prep.lisp"): The value -3 is not of type (MOD 536870911). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing #<LOAD-OP NIL {5A1394A9}> on #<CL-SOURCE-FILE "edifact-generation" {5A139499}>. 1: [ACCEPT ] Continue, treating #<LOAD-OP NIL {5A1394A9}> on #<CL-SOURCE-FILE "edifact-generation" {5A139499}> as having been successful. 2: [CONTINUE] Ignore and continue with next --eval option. 3: [ABORT ] Skip rest of --eval options. 4: Skip to toplevel READ/EVAL/PRINT loop. 5: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ((LAMBDA (SB-IMPL::E)) #<TYPE-ERROR {59B197C1}>) 0] backtrace 0: ((LAMBDA (SB-IMPL::E)) #<TYPE-ERROR {59B197C1}>) 1: ((LAMBDA (SB-IMPL::E)) #<TYPE-ERROR {59B197C1}>) 2: (SIGNAL #<TYPE-ERROR {59B197C1}>) 3: (ERROR TYPE-ERROR) 4: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XF7A15224) #<ALIEN-VALUE :SAP #XF7A14EB8 :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T- STRUCT))> (13 78)) 5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XF7A14EB8) #<unavailable argument>) 6: ("foreign function: call_into_lisp") 7: ("foreign function: funcall2") 8: ("foreign function: interrupt_internal_error") 9: ("foreign function: sigtrap_handler") 10: ("foreign function: #xDD21C") 11: (SB-PCL::FIND-FREE-CACHE-LINE -1 #<SB-PCL::CACHE 2 T 4 {59A1DC49}> (#<SB-PCL::WRAPPER #<STANDARD-CLASS EDIFACT-OUTPUT-SIMPLE- ELEMENT> {596354B9}> #<SB-KERNEL:LAYOUT for T {560603F1}>)) 12: (SB-PCL::FILL-CACHE-P NIL #<SB-PCL::CACHE 2 T 4 {59A1DC49}> (#<SB-PCL::WRAPPER #<STANDARD-CLASS EDIFACT-OUTPUT-SIMPLE- ELEMENT> {596354B9}> #<SB-KERNEL:LAYOUT for T {560603F1}>) #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) :ARG-INFO (2))) 13: (SB-PCL::FILL-CACHE #<SB-PCL::CACHE 2 T 4 {59A1DC49}> (#<SB-PCL::WRAPPER #<STANDARD-CLASS EDIFACT-OUTPUT-SIMPLE- ELEMENT> {596354B9}> #<SB-KERNEL:LAYOUT for T {560603F1}>) #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) :ARG-INFO (2))) 14: ((FLET SB-PCL::ADD-CLASS-LIST) (#<STANDARD-CLASS EDIFACT-OUTPUT-SIMPLE-ELEMENT> #<BUILT-IN- CLASS T>)) 15: (SB-PCL::MAKE-EMF-CACHE #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (251)> T #<unavailable argument> NIL NIL) 16: (SB-PCL::MAKE-FINAL-CACHING-DFUN #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (251)> NIL NIL) 17: (SB-PCL::MAKE-FINAL-DFUN-INTERNAL #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (251)> NIL) 18: (SB-PCL::MAKE-FINAL-DFUN #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (251)> NIL) 19: (SB-PCL::UPDATE-DFUN #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (251)> NIL NIL NIL) 20: ((SB-PCL::FAST-METHOD REINITIALIZE-INSTANCE :AROUND (STANDARD-GENERIC-FUNCTION)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (251)> NIL) 21: (SB-PCL::REAL-ENSURE-GF-USING-CLASS--GENERIC-FUNCTION #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (251)> PRINT-OBJECT #<unavailable &REST argument> :ENVIRONMENT NIL :LAMBDA-LIST NIL :GENERIC-FUNCTION-CLASS STANDARD-GENERIC-FUNCTION) 22: (SB-PCL::REAL-ADD-NAMED-METHOD PRINT-OBJECT NIL (FOO T) (M STREAM) :DEFINITION-SOURCE #S(SB-C:DEFINITION-SOURCE-LOCATION :NAMESTRING "edifact-generation.lisp" :TOPLEVEL-FORM-NUMBER 2 :PLIST NIL) :METHOD-SPEC (SB-PCL::SLOW-METHOD PRINT-OBJECT (FOO T)) :FAST-FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD PRINT-OBJECT #) {599FC235}> :PLIST (:ARG-INFO (2) :CONSTANT-VALUE NIL)) 23: (SB-PCL::LOAD-DEFMETHOD-INTERNAL STANDARD-METHOD PRINT-OBJECT NIL (FOO T) (M STREAM) #<unavailable argument> NIL #S(SB-C:DEFINITION-SOURCE-LOCATION :NAMESTRING "edifact-generation.lisp" :TOPLEVEL-FORM-NUMBER 2 :PLIST NIL)) 24: (SB-FASL::LOAD-FASL-GROUP #<SB-SYS:FD-STREAM for "file edifact-generation.fasl" {599F9D09}>) 25: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file edifact-generation.fasl" {599F9D09}> NIL #<unavailable argument>) |
From: Christophe R. <cs...@ca...> - 2006-07-25 08:49:58
|
James Y Knight <fo...@fu...> writes: > We've managed to narrow down the file causing the error to the > following small snippet. HOWEVER, this code doesn't actually cause an > issue standing alone (even with the base classes defined/etc). By the time you load this snippet, are the other classes actually defined? Or do they get defined later? > Only > after loading the rest of our system, does this code crash. Is there > anything useful I could look at the time this file starts being > compiled to determine what could be corrupted and causing this? It > seems like some subtle corruption... Does your full system (when you have a crash) have a print-object method on some superclass of edifact-output-simple-element (distinct from the system print-object method, of course)? The reason that this is relevant is that generic functions in the CL and SB-PCL packages are treated specially by the discriminating function machinery, filling caches eagerly rather than lazily -- but it will only fill the cache for a given class if there is a non-system applicable method. In the case when this file breaks, do any of the DEFCLASSes redefine incompatibly any previously-existing class? Either one with the same name, or else a previously-forward-referenced class? > (defclass FOO () ()) > (defmethod print-object ((m FOO) stream) nil) > (eval-when (:compile-toplevel :load-toplevel :execute) > (defclass edifact-output-element (base-edifact-segment) ()) > (defclass edifact-output-simple-element (edifact-output-element) > ((name :accessor edifact-element-name))) > ) My guess for what is happening is that there simply wasn't any defensive coding against invalid wrappers at all in MAKE-EMF-CACHE, and my tiny bit of defense against an intermediate finalization/invalidation (by CPL-OR-NIL) is simply not enough. It's quite possible that now invalid wrappers propagate for longer, and one simply has to defend against that in (say) GET-WRAPPERS-FROM-CLASSES. Could you check that the class causing the error in your setup is actually finalized? (I think it must be). Can you see if any class is incompatibly redefined in your real system? Cheers, Christophe |
From: James Y K. <fo...@fu...> - 2006-07-24 23:39:30
|
A few more bits: Inside the flet add-class list inside make-emf-cache, it calls update- class on the superclass of EDIFACT-OUTPUT-SIMPLE-ELEMENT. This invalidates the layouts of that superclass and its subclasses. This call recursively calls update-class on EDIFACT-OUTPUT-SIMPLE-ELEMENT, yet, somehow, that same invalidated layout seemingly never got replaced, and later in the loop, wrappers and %wrappers still have that invalid layout for EDIFACT-OUTPUT-SIMPLE-ELEMENT. Anything occur to you that would cause the wrapper to not be replaced, but rather left with invalid set to t? I'm hoping there's enough info to track this down soon...it's quite difficult for me to trace through the convoluted and utterly uncommented PCL code. Perhaps the anonymous class change should be reverted for the upcoming release? James |
From: Christophe R. <cs...@ca...> - 2006-07-25 10:12:53
|
James Y Knight <fo...@fu...> writes: > Inside the flet add-class list inside make-emf-cache, it calls update- > class on the superclass of EDIFACT-OUTPUT-SIMPLE-ELEMENT. This > invalidates the layouts of that superclass and its subclasses. This > call recursively calls update-class on EDIFACT-OUTPUT-SIMPLE-ELEMENT, > yet, somehow, that same invalidated layout seemingly never got > replaced, and later in the loop, wrappers and %wrappers still have > that invalid layout for EDIFACT-OUTPUT-SIMPLE-ELEMENT. Anything occur > to you that would cause the wrapper to not be replaced, but rather > left with invalid set to t? UPDATE-SLOTS only replaces a wrapper if the layout has changed incompatibly, I think. So, if there hasn't been any change in the slots, calling UPDATE-LISP-CLASS-LAYOUT is a no-op; so on returning from update-class it's still possible to have an invalid layout. (I'm pretty sure this is by design). > Perhaps the anonymous class change should be reverted for the upcoming > release? I'd much rather not revert. With the change, it passes the SBCL test suite and compiles and runs a substantial body of code (of the order of 50 ASDF systems) that I've tested it on; in the absence of an actual test case from you, I'd prefer to get it into the wild, and if someone else comes up with a reduced test case, so much the better. Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2006-07-25 11:05:08
|
James Y Knight <fo...@fu...> writes: > 11: (SB-PCL::FIND-FREE-CACHE-LINE > -1 > #<SB-PCL::CACHE 2 T 4 {59A1DC49}> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (#<SB-PCL::WRAPPER #<STANDARD-CLASS EDIFACT-OUTPUT-SIMPLE- > ELEMENT> {596354B9}> > #<SB-KERNEL:LAYOUT for T {560603F1}>)) I've worked out what's different between your setup and mine. Someone, somewhere has in your code specialized on the second argument of PRINT-OBJECT. Here's a reduced test case for your problem: (defclass base () ()) ;; PRINT-OBJECT is a handy function with PRECOMPUTE-P T (defmethod print-object ((o base) (s stream)) nil) (defclass sub (base) ()) ;; having an accessor finalizes the class eagerly. (defclass subsub (sub) ((a :accessor a))) (reinitialize-instance #'print-object) and the problem you're seeing is in fact commented on in a FIXME note in FILL-CACHE-P. I still think it's wrong to have invalid wrappers in caches, and yet we seem to put them there, even before all the recent changes. As I said in that comment, way back in April, I got utterly confused. I can't fathom when it is right either to pass an invalid wrapper to fill a cache, or to probe a cache with invalid wrappers; maybe an intrepid explorer would find all the callers of FILL-CACHE and arrange that invalid wrappers never get that far, and see if anything breaks. The alternative would be to make the cacheing code more defensive against invalid wrappers, but that doesn't seem like the right answer. Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2006-07-25 16:07:43
|
Christophe Rhodes <cs...@ca...> writes: > I've worked out what's different between your setup and mine. > Someone, somewhere has in your code specialized on the second argument > of PRINT-OBJECT. > > Here's a reduced test case for your problem: > > (defclass base () ()) > ;; PRINT-OBJECT is a handy function with PRECOMPUTE-P T > (defmethod print-object ((o base) (s stream)) > nil) > > (defclass sub (base) ()) > ;; having an accessor finalizes the class eagerly. > (defclass subsub (sub) > ((a :accessor a))) > > (reinitialize-instance #'print-object) For what it's worth, I've committed this test case and a fix for it in sbcl-0.9.14.32. Desperately close to the wire, I know, but I'm pretty happy I understand what's going on. Cheers, Christophe |