out-of-bounds errors with SLOT-VECTORs

[Arthur]

I have run into this kind of problem many times with my EasyGui efforts, and thought it must be my own fault. But now I've come across it using the Search Files dialog, which is nothing to do with me. This kind of thing pops up in the AltConsole? window:

Error: Array index 5 out of bounds for #<SLOT-VECTOR [CCL::SLOT-VECTOR ==> CCL::GVECTOR ==> T] #x136DC716> . While executing: (:INTERNAL GUI::|-doSearch:?|), in process Initial(0). Type :POP to abort, :R for a list of available restarts. Type :? for other options.

1 >

It is not reliably repeatable.

fwiw, I have suspected that it is due to some race condition whereby instances of Cocoa subclasses get information enough added to them for some objc method to be dispatched, but the extra Lisp slots appropriate for the class have not yet been added. This is just a hunch, maybe helpful and maybe way off the mark.

[Arthur]

by the way, the info provided in the message is due to my own print-function, which I had added in an effort to learn more about these errors.

[ender2012]

Backtrace

[ender2012]

I have also experienced this problem unfortunately it is not very reproducible. Part of our application includes an editor that is an NSOpenGLView that contains objects that popup windows to make selections when you click on them. A small percentage of the time when you make a selection in this window, we get the array index out of bounds. Usually the index being referenced is one greater then the last slot in the object. For example in the backtrace I included line 7:

7 (%STD-SLOT-VECTOR-VALUE #<SLOT-VECTOR #xAB953AE> #<STANDARD-EFFECTIVE-SLOT-DEFINITION for instance slot LUI::NAME #x9B8A7EE>) 296

references the name accessor of my indexed-image-view class:

(defclass INDEXED-IMAGE-VIEW (ns:ns-image-view)

((index :accessor index :initform 200 :initarg :index :documentation "index of button")

(lui-superview :accessor lui-superview :initform nil :initarg :lui-superview) (selected :accessor selected :initform nil) (name :accessor name :initform nil))

(:metaclass ns:+ns-object

:documentation "Index Button"))

The name slot is the 4th out of 4 slots and it seems that that somehow the 5th slot of this class was trying to be accessed which does not exist.

[gb]

An instance's slots (those with :ALLOCATION :INSTANCE) are stored in an auxiliary vector (called, of all things, a SLOT-VECTOR.) In general, an instance's class can be redefined and that redefinition can change the number of instance slots to change, making this extra level of indirection necessary.

The 0th element of each SLOT-VECTOR points back the containing instance; subsequent elements (starting at index 1) contain the instance's slots' values. So, instances of a class which has 4 local slots should have 5-element SLOT-VECTORs, and the value of the 4th slot should be accessed by referencing the 4th element (not the 3rd) of the slot-vector.

This doesn't explain why out-of-bounds accesses are occurring (why the slot-vector doesn't have the expected number of elements), but the fact that the index being used is one greater than expected is ... expected.

[gb]

This may have been fixed in r14202/r14203.

An earlier attempt to fix this in r14198 introduced a number of other, more severe problems.

If people who've experienced this problem (confusion about foreign instances' slot-vectors) can upgrade to r14203 or later (in the trunk), it'd be helpful to know whether that problem is still present.

[ender2012]

I updated to r14211 on Wednesday and have been testing since then (also one of our interns has been testing and trying to trigger this bug) and so far we have not experienced the array index crash. This bug was inconsistent so I would say it is to early to use this as proof that the issue has been resolved but I believe it is very likely that this bug was fixed in r14202/r14203. I will continue testing and report back at the end of next week.

[Arthur]

I also have upgraded, and seen no recurrence of the problem since then. The signs are good, but as ender2012 says, it always was intermittent. Nevertheless, I regard it as fixed until shown otherwise.

Thank you.

Arthur

[gb]

If anyone sees this bug reappear, please reopen this ticket.