Hey David, I ran in to the same problem Mathias mentioned. It's easy to hit if you're managing some resource with GCD, and that resource needs to be closed in -dealloc (in my case, it's the database connection in CoreObject that I only access within a particular dispatch queue, and I need to close the connection in -dealloc).
You can trigger the failure just by using a block in dealloc that
causes self to be retained:
- (void) dealloc
{
void (^myBlock)() = ^() {
id foo = self;
NSLog(@"inside myBlock, foo = %p", foo);
};
myBlock();
}
I attached this reduced test case and a naiive patch to arc.m that
makes the test case work, but it's an ugly hack and I'm sure it's
broken in various ways.
In CoreObject, I think I can work around this for now by creating the
block ahead of time, in -init.
Eric
On Mon, Feb 17, 2014 at 6:39 AM, David Chisnall
<[email protected]> wrote:
> On 17 Feb 2014, at 13:33, Mathias Bauer <[email protected]> wrote:
>
>> in case somebody else is also interested in this: it seems that Apple's
>> runtime "protects" the developer by ignoring changes to the retain count as
>> soon as the object entered its deallocate method. Wrong decision, IMHO.
>
> It is likely that this is a side effect of weak reference support. Classes
> must notify the runtime when they start deallocation now, so that concurrent
> loads of weak references abort the deallocation. Apple's implementation
> stores objects' refcounts in a map table, so once the object has entered
> deallocation it's likely just a separate path. I wouldn't be surprised if
> this is not an active decision at all, however it does make adding cycle
> detection to ARC easier...
>
> David
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
arcbug.tgz
Description: GNU Zip compressed data
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
