[Openmcl-devel] Array out of bounds errors with ns:+ns-object

Alexander Repenning ralex at cs.colorado.edu
Thu Feb 16 22:33:26 UTC 2012


I think this precisely that is happening. Now, with calling OBJC:REMOVE-LISP-SLOTS from #/alloc the problem appears to have gone away.

thanks!

Alex


On Feb 15, 2012, at 5:23 PM, Gary Byers wrote:

> A CCL::SLOT-VECTOR's 0th element is a backpointer to the containing
> instance; the values of the instance's slots are in elements 1..n.
> There's nothing anomalous about trying to access element 2 of a slot
> vector associated with an instance that has 2 lisp instance slots; the
> anomaly is that a SLOT-VECTOR that apparently only has one slot is
> associated with an instance that has two slots.
> 
> There's a hash table that maps instances of ObjC classes that're
> defined to have lisp slots to the SLOT-VECTOR that contains the
> instance's slot valiues.  That's an oversimplification: the hash table
> really maps foreign addresses to slot vectors.  The mapping ceases to
> become valid when the ObjC object at a particular address is
> deallocated.  In order to ensure that the mapping is broken when the
> instance is (about to be) deallocated.  Whenever a class that's
> defined to have lisp slots associated with its instances is defined, a
> #/dealloc method is automatically defined which calls OBJC:REMOVE-LISP-SLOTS
> to break the mapping (and calls the next method to ultimately cause the
> ObjC object to be deallocated.)
> 
> You can redefine this automatically-generated #/dealloc method, but it's
> critical that the redefinition calls OBJC:REMOVE-LISP-SLOTS if the class
> in question has lisp slots.
> 
> Since an ObjC instance can be created by foreign code (by an #/init method or
> equivalent), slot-vectors can be created on-demand (when they're first accessed.)
> The code that tries to access the slot-vector associated with an ObjC instance
> either looks in the hash table to see if a mapping already exists between the
> instance (actually, its address) and a slot vector and either uses an existing
> mapping or establishes a new one.
> 
> If a #/dealloc method is defined on instances of classes that have lisp slots
> and the method neglects to call OBJC:REMOVE-LISP-SLOTS, then a scenario like
> the following can occur:
> 
> 1) An instance of some ObjC class for which one lisp slot is defined
> is created (at some foreign address A).  A slot-vector for the
> instance is created and associated with address A.
> 
> 2) The instance is deallocated but the mapping between A and the slot-vector
> remains.
> 
> 3) At some later point, an instance of some (quite possibly different) ObjC
> class is created and happens to also have the foreign address A.  When the
> instance's slot-vector needs to be (lazily) accessed, the old (deallocated)
> instance's slot-slot vector is (re-)used, and wackiness ensues.  (We could
> refuse to reuse a slot-vector of the wrong size and avoid the particular
> problem that you're seeing, but that'd just allow other (possibly much more
> subtle) kinds of wackiness to occur.
> 
> You're right in remembering that this used to be more common; the
> workaround (of automatically defining #/dealloc methods) was
> introduced in 1.6, and the issue (where user-defined #/dealloc methods
> have to call OBJC:REMOVE-LISP-SLOTS) is discussed in the 1.6 release
> notes.
> 
> What I'm calling "lisp slots" (slots associated with instances of ObjC classes
> where the slot-definition clauses don't have a :FOREIGN-TYPE option) are fairly
> expensive, and it's generally preferable and not a whole lot different to use
> the :FOREIGN-TYPE option when that's applicable (as I'd guess it is in your
> example.)
> 
> I have no way of knowing for sure, but I think it's likely that this is what
> you're running into.
> 
> On Wed, 15 Feb 2012, Alexander Repenning wrote:
> 
>> Very strange and super hard to reproduce slot access error with ns:+ns-object objects happening on CCL Windows with Cocotron (Version 1.7-dev  (WindowsX8632)!)
>> 
>> This is the class definition:
>> 
>> 
>> (defclass NATIVE-COLOR-WELL-BUTTON (ns:ns-button)
>> ((lui-view :accessor lui-view :initarg :lui-view)
>> (native-color :accessor native-color :initform nil :initarg :native-color))
>> (:metaclass ns:+ns-object))
>> 
>> 
>> works fine 99% of the time when accessing NATIVE-COLOR but then, once in a while we get the error below. Assuming the slots of NATIVE-COLOR-WELL-BUTTON would be index 0 and 1 then CCL tries to access, occasionally, native-color as slot index 2. How can the slot access fail sometimes. What could the source of non deterministic behavior be?  I think I remember some similar problem with some CCL window function a long time ago. That got fixed but how? I assume that threading may be involved in the problem. Any ideas?
>> 
>> 
>> best,  Alex
>> 
>> 
>> 
>>> Error: Array index 2 out of bounds for #<SLOT-VECTOR #xCBE4176> .
>> 
>>> While executing: (:INTERNAL LUI::|-[NativeColorWellButton drawRect:]|), in pro
>> 
>> cess Initial(0).
>> 
>>> Type :POP to abort, :R for a list of available restarts.
>> 
>>> Type :? for other options.
>> 
>> 1 > :b
>> 
>> (24078C0) : 0 (FUNCALL #'#<(:INTERNAL LUI::|-[NativeColorWellButton drawRect:]|
>> 
>> )> #<SIMPLE-ERROR #xCC4B6EE>) 143
>> 
>> (24078D4) : 1 (SIGNAL #<SIMPLE-ERROR #xCC4B6EE>) 879
>> 
>> (24078FC) : 2 (%ERROR #<SIMPLE-ERROR #xCC4B6EE> (2 #<SLOT-VECTOR #xCBE4176>) 94
>> 
>> 44976) 111
>> 
>> (2407910) : 3 (FUNCALL #'#<(:INTERNAL CCL::%XERR-DISP)>) 2351
>> 
>> (2407938) : 4 (FUNCALL-WITH-ERROR-REENTRY-DETECTION #<CCL:COMPILED-LEXICAL-CLOS
>> 
>> URE (:INTERNAL CCL::%XERR-DISP) #x51F74E>) 183
>> 
>> (2407958) : 5 (FUNCALL #'#<CCL::%XERR-DISP> 899610) 471
>> 
>> (2407978) : 6 (%PASCAL-FUNCTIONS% 2 899610) 343
>> 
>> *(24079C0) : 7 (%STD-SLOT-VECTOR-VALUE #<SLOT-VECTOR #xCBE4176> #<STANDARD-EFFEC
>> 
>> TIVE-SLOT-DEFINITION for instance slot LUI::NATIVE-COLOR #x844E69E>) 288
>> 
>> (24079F4) : 8 (FUNCALL #'#<LUI::|-[NativeColorWellButton drawRect:]|> 900310) 4
>> 
>> 119
>> 
>> (2407A2C) : 9 (%PASCAL-FUNCTIONS% 413 900310) 343
>> 
>> (2407A74) : 10 (FUNCALL #'#<Anonymous Function #x4DC62D6> #<MENULESS-NATIVE-WIN
>> 
>> DOW <MenulessNativeWindow 0x4b0806d0> (#x4B0806D0)> #S(CCL::OBJC-SELECTOR :NAME
>> 
>> "orderFront:" :%SEL #<A Foreign Pointer #x2AD5E74>) NIL) 407
>> 
>> (2407A88) : 11 (FUNCALL #'#<(:OBJC-DISPATCH NEXTSTEP-FUNCTIONS:|orderFront:|)>
>> 
>> ???) 975
>> 
>> (2407AC0) : 12 (FUNCALL #'#<(:INTERNAL #:G49563 (SHOW (WINDOW)))>) 79
>> 
>> (2407AD4) : 13 (HANDLE-INVOKING-LISP-FUNCTION #<CCL:COMPILED-LEXICAL-CLOSURE (:
>> 
>> INTERNAL #:G49563 #) #xCC4B76E> NIL NIL #<APPKIT-PROCESS Initial(0) [Reset] #xC0
>> 
>> 5E94E>) 567
>> 
>> (2407B0C) : 14 (FUNCALL #'#<#<STANDARD-METHOD SHOW (WINDOW)>> <inflatable-icon-
>> 
>> editor-window x="100" y="138" width="1020" height="400"/>) 287
>> 
>> (2407B24) : 15 (FUNCALL #'#<#<STANDARD-METHOD INITIALIZE-INSTANCE :AFTER (APPLI
>> 
>> CATION-WINDOW)>> <inflatable-icon-editor-window x="100" y="138" width="1020" hei
>> 
>> ght="400"/> :IS-CREATED-BY-XML-READER T :FILE #P"C:/Program Files (x86)/AgentShe
>> 
>> ets INC/AgentCubesb3rc1/AgentCubes.app/Contents/resources/windows/inflatable-ico
>> 
>> n-editor-windows.window" :TRACK-MOUSE T :RESIZABLE T :MIN-WIDTH 50 :MIN-HEIGHT 5
>> 
>> 0 :DO-SHOW-IMMEDIATELY T :X 100 :Y 100 :WIDTH 340 :HEIGHT 180) 295
>> 
>> (2407B38) : 16 (%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE (NIL #<STANDARD-METHOD
>> 
>> INITIALIZE-INSTANCE :AFTER #> . 9445096)) 1207
>> 
>> (2407B78) : 17 (%%STANDARD-COMBINED-METHOD-DCODE (NIL (#<#> #<#> #<#>) #<STANDA
>> 
>> RD-METHOD INITIALIZE-INSTANCE #> #<STANDARD-METHOD INITIALIZE-INSTANCE #> #<CCL:
>> 
>> :STANDARD-KERNEL-METHOD INITIALIZE-INSTANCE #>) 9445096) 207
>> 
>> (2407C00) : 18 (%MAKE-STD-INSTANCE #<STANDARD-CLASS INFLATABLE-ICON-EDITOR-WIND
>> 
>> OW> (:IS-CREATED-BY-XML-READER T :FILE #P"C:/Program Files (x86)/AgentSheets INC
>> 
>> /AgentCubesb3rc1/AgentCubes.app/Contents/resources/windows/inflatable-icon-edito
>> 
>> r-windows.window" :TRACK-MOUSE ...)) 359
>> 
>> (2407C14) : 19 (FUNCALL #'#<#<CCL::STANDARD-KERNEL-METHOD MAKE-INSTANCE (STANDA
>> 
>> RD-CLASS)>> #<STANDARD-CLASS INFLATABLE-ICON-EDITOR-WINDOW> :IS-CREATED-BY-XML-R
>> 
>> EADER T :FILE #P"C:/Program Files (x86)/AgentSheets INC/AgentCubesb3rc1/AgentCub
>> 
>> es.app/Contents/resources/windows/inflatable-icon-editor-windows.window") 135
>> 
>> (2407C28) : 20 (FUNCALL #'#<#<CCL::STANDARD-KERNEL-METHOD MAKE-INSTANCE (SYMBOL
>> 
>> )>> INFLATABLE-ICON-EDITOR-WINDOW :IS-CREATED-BY-XML-READER T :FILE #P"C:/Progra
>> 
>> m Files (x86)/AgentSheets INC/AgentCubesb3rc1/AgentCubes.app/Contents/resources/
>> 
>> windows/inflatable-icon-editor-windows.window") 183
>> 
>> (2407C3C) : 21 (READ-NAME-AND-MAKE-INSTANCE #<BASIC-FILE-CHARACTER-INPUT-STREAM
>> 
>> ("lui:resources;windows;inflatable-icon-editor-windows.window"/3172 ISO-8859-1)
>> 
>> #xCC2D226>) 535
>> 
>> (2407C58) : 22 (ELEMENT-READER #<BASIC-FILE-CHARACTER-INPUT-STREAM ("lui:resour
>> 
>> ces;windows;inflatable-icon-editor-windows.window"/3172 ISO-8859-1) #xCC2D226> #
>> 
>> \<) 375
>> 
>> (2407C78) : 23 (%PARSE-EXPRESSION #<BASIC-FILE-CHARACTER-INPUT-STREAM ("lui:res
>> 
>> ources;windows;inflatable-icon-editor-windows.window"/3172 ISO-8859-1) #xCC2D226
>> 
>>> #\< NIL) 551
>> 
>> (2407CA4) : 24 (%READ-FORM #<BASIC-FILE-CHARACTER-INPUT-STREAM ("lui:resources;
>> 
>> windows;inflatable-icon-editor-windows.window"/3172 ISO-8859-1) #xCC2D226> 0 NIL
>> 
>> ) 543
>> 
>> (2407CC0) : 25 (READ-INTERNAL #<BASIC-FILE-CHARACTER-INPUT-STREAM ("lui:resourc
>> 
>> es;windows;inflatable-icon-editor-windows.window"/3172 ISO-8859-1) #xCC2D226> T
>> 
>> NIL NIL) 247
>> 
>> (2407CFC) : 26 (READ #<BASIC-FILE-CHARACTER-INPUT-STREAM ("lui:resources;window
>> 
>> s;inflatable-icon-editor-windows.window"/3172 ISO-8859-1) #xCC2D226> T NIL NIL)
>> 
>> 143
>> 
>> (2407D24) : 27 (LOAD-OBJECT "lui:resources;windows;inflatable-icon-editor-windo
>> 
>> ws.window" :VERBOSE NIL :IF-DOES-NOT-EXIST :ERROR :PACKAGE #<Package "XLUI">) 43
>> 
>> 9
>> 
>> (2407D88) : 28 (NEW-INFLATABLE-ICON-EDITOR-WINDOW-FROM-IMAGE "C:/Users/AgentCub
>> 
>> esTester/Desktop/Maze Craze/agents/Chaser/shapes/Chaser/redLobster.png" :SAVE-BU
>> 
>> TTON-CLOSURE-ACTION #<CCL:COMPILED-LEXICAL-CLOSURE (:INTERNAL #) #xCC2D246> :SHA
>> 
>> PE-NAME "CHASER" :SHAPE-FILENAME "index" :DESTINATION-INFLATABLE-ICON NIL :CLOSE
>> 
>> -ACTION NIL :ALERT-CLOSE-ACTION ICON-WINDOW-HAS-CLOSED :ALERT-CLOSE-TARGET <agen
>> 
>> t-gallery width="170" height="150"/>) 295
>> 
>> (2407DE4) : 29 (FUNCALL #'#<#<STANDARD-METHOD EDIT-GROUP-ITEM (AGENT-GALLERY-VI
>> 
>> EW T T)>> <agent-gallery width="170" height="150"/> "Chaser" "Chaser") 1231
>> 
>> (2407E08) : 30 (FUNCALL #'#<LUI::|-[GroupDetectionView mouseDown:]|> 900882) 98
>> 
>> 3
>> 
>> (2407E3C) : 31 (%PASCAL-FUNCTIONS% 466 900882) 343
>> 
>> (2407E84) : 32 (FUNCALL #'#<Anonymous Function #x4DC64DE> #<A Foreign Pointer [
>> 
>> stack-allocated] (:* #) #x36FD30> #<A Foreign Pointer #x2AA8974> #<NS-EVENT <NSE
>> 
>> vent_mouse[0x45c04420] type: 1> (#x45C04420)>) 383
>> 
>> (2407E98) : 33 (%CALL-NEXT-OBJC-METHOD #<LISP-APPLICATION <LispApplication 0x02
>> 
>> db3250> (#x2DB3250)> #<OBJC:OBJC-CLASS GUI::LISP-APPLICATION (#x54F550)> #<A For
>> 
>> eign Pointer #x2AA8974> (:VOID :ID) #<NS-EVENT <NSEvent_mouse[0x45c04420] type:
>> 
>> 1> (#x45C04420)>) 1239
>> 
>> (2407EE8) : 34 (FUNCALL #'#<GUI::|-[LispApplication sendEvent:]|> 900974) 879
>> 
>> (2407F20) : 35 (%PASCAL-FUNCTIONS% 16 900974) 343
>> 
>> (2407F68) : 36 (FUNCALL #'#<Anonymous Function #x4D409FE> #<LISP-APPLICATION <L
>> 
>> ispApplication 0x02db3250> (#x2DB3250)> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL
>> 
>> #<A Foreign Pointer #x286D479>)) 191
>> 
>> (2407F78) : 37 (FUNCALL #'#<(:OBJC-DISPATCH NEXTSTEP-FUNCTIONS:|run|)> ???) 975
>> 
>> 
>> 
>> (2407FB0) : 38 (EVENT-LOOP NIL) 367
>> 
>> (2407FD8) : 39 (FUNCALL #'#<(:INTERNAL GUI::COCOA-STARTUP GUI::START-COCOA-APPL
>> 
>> ICATION)>) 783
>> 
>> 1 >
>> 
>> 
>> 
>> 
>> Prof. Alexander Repenning
>> 
>> University of Colorado
>> Computer Science Department
>> Boulder, CO 80309-430
>> 
>> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>> 
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>> 
>> 

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clozure.com/pipermail/openmcl-devel/attachments/20120216/e7a5d95f/attachment.html>


More information about the Openmcl-devel mailing list