Re: Multithreading crash in -[NSConditionLock unlockWithCondition:]
Re: Multithreading crash in -[NSConditionLock unlockWithCondition:]
- Subject: Re: Multithreading crash in -[NSConditionLock unlockWithCondition:]
- From: Quincey Morris <email@hidden>
- Date: Wed, 23 Jan 2013 23:07:59 -0800
On Jan 23, 2013, at 22:38 , Jerry Krinock <email@hidden> wrote:
> 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 dunno about this theory in particular, but it's worth noting that pretty most manual retain/release code was technically flawed, in that it generally relied on an assumption that an object pointer in a local variable would not get deallocated until at least the method containing the variable returned. The most usual failure of this assumption came when it was actually being kept alive by an autorelease, and something drained the pool prematurely. Normally, though the assumption was safe enough.
This may be an example when the assumption isn't safe.
> I suppose that if this old project had been built with ARC I never would have had this bug?
It depends. What's the source code line that invokes 'unlockWithCondition:'?
If it's sending that message to a local variable, then the ARC version is safe, since the local variable keeps the object alive until it (the variable) goes out of scope.
If it's sending that message to an ivar, then the ARC version is unsafe, if another thread might nil the ivar while the method is executing, as you speculate might be happening. ARC won't save you here (unless you invoke 'unlockWithCondition:' via a local variable, of course).
From a different perspective, though, this isn't a memory management issue, but rather a thread safety issue. You have your lock protecting some shared resource or other, but your lock is itself a shared resource, and nothing is protecting *it*. That's the real bug.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden