Opened 11 years ago

Closed 10 years ago

#706 closed defect (fixed)

out-of-bounds errors with SLOT-VECTORs

Reported by: Arthur Owned by:
Priority: normal Milestone:
Component: Objective-C Bridge Version: trunk
Keywords: Cc:


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.

Attachments (1)

Clozure CL32-296e.log (49.5 KB) - added by ender2012 10 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 11 years ago by 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.

Changed 10 years ago by ender2012


comment:2 Changed 10 years ago by 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:


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.

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by 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.


comment:7 Changed 10 years ago by gb

  • Component changed from IDE to Objective-C Bridge
  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.