I received a crash report from a user indicating EXC_BAD_ACCESS in -[NSConditionLock unlockWithCondition:]. Since the 'condition' parameter is an integer, I think the only explanation is that the receiver must have been deallocced. That didn't seem possible at the time when -unlockWithCondition: was invoked, but the lock was released (and deallocced) on another thread, which was blocked waiting for this lock to be unlocked. After inserting an extra -retain and testing it for a time myself I found that, on rare occasions, the retain count was one less than expected.
My theory is that, on these rare occasions, the thread running -unlockWithCondition: would run enough to unblock the other thread, and, oddly but legally, the system would then pause this thread before this method had returned, and run the other thread, which would dealloc the lock. Then, upon resuming the first thread, the remaining code in -unlockWithCondition: would send some message to its deallocced self, causing EXC_BAD_ACCESS. I suppose that if this old project had been built with ARC I never would have had this bug? _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
