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

Wed Feb 15 16:23:18 PST 2012

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
>
>