Are you sure you are only updating on the main thread?
Why the use of @synchronized in the above if updates only take place
on the main thread?
-Shawn
Yes, I'm sure, I've checked the [NSThread currentThread]. I wasn't
sure about the @synchronized (ugly Java days), so I removed it and
the same crash occurs. But I did a few changes :
- instead of calling unionSet:, I'm calling setSet;
- updated the willChangeValueForKey (to match the call);
And the program still crashes when scrolling while the set is
updated. Sometimes, the debug log shows me (when I have more rooms
inside the set than the replacement) :
2007-07-31 15:07:00.125 SolarSeek[565] *** Selector
'removeObserver:forKeyPath:' sent to dealloced instance 0x26334070 of
class NSDistantObject.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.
2007-07-31 15:07:00.125 SolarSeek[565] *** Selector
'removeObserver:forKeyPath:' sent to dealloced instance 0x26334070 of
class NSDistantObject.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.
Just after the list being updated in the main thread. I've checked
all the items inside the set, the entire tree, and no item with a
pointer value of 0x26334070
was allocated by my classes (in that session).
