.. and of course having asked the question I found the answer.
First, to track it down, I used allocations in instruments, set to track all
objects and enable zombies. Cycling through one time I got the dialog telling
me I'd sent release to a zombie and got the full history.
The message was misleading as release wasn't the first thing sent to the object
after dealloc(), it was a load of retains and autoreleases, 13 of them.
Eventually when the first autorelease pool popped a real release was sent to an
object which instruments thought had 13 retains, but actually had zero as it
had been dealloced. That caused the crash.
The actual reason was that during dealloc, there were a few method calls, one
of which eventually used a property of the object being dealloced. This line of
code
return self.delegate == delegateArg
caused self to get a retain/autorelease, resurrecting the object. The change to
use the ivar directly fixed it. I'm careful accessing properties in dealloc
for that very reason, this slipped through when I refactored out a test into a
method call.
So ... the way you get an over release with ARC is one of the same ways you do
it with manual refcounting, you cause a retain during dealloc.
On 24 Dec, 2011, at 12:38, Roland King <r...@rols.org> wrote:
> I can't find this one. I have a crash in my app, message being sent to
> deallocated instance. I enabled zombies and get the following (first line is
> a log in the dealloc() method of my object, second one is from the zombies
> framework).
>
> 2011-12-24 12:23:04.317 Hippo[17279:fb03] HIPTopicView 0x6b6f230 deallocing
> 2011-12-24 12:23:10.962 Hippo[17279:fb03] *** -[HIPTopicView release]:
> message sent to deallocated instance 0x6b6f230
>
> This app uses entirely ARC and nothing else, there is no manual reference
> counting anywhere in the whole app. The message sent is release, which means
> we have an overrelease. I can think of no way barring a bug in ARC itself
> that could possibly happen, can anyone else think of a way you could get an
> overrelease with purely ARC code? The stack trace shows this to be in an
> autorelease pool pop, so it really looks as if ARC has generated one more
> autorelease than it has retain.
>
> Secondly, can anyone think of a way to dig down deeper and find where it
> might be, even so I can file a bug report on it. I'm just about to try wild
> random code refactoring as I'm running rapidly out of ideas.
>
>
> _______________________________________________
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>
> This email sent to r...@rols.org
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
