Re: Can I somehow encourage the deallocation of a dismissed view controller?
Re: Can I somehow encourage the deallocation of a dismissed view controller?
- Subject: Re: Can I somehow encourage the deallocation of a dismissed view controller?
- From: Conrad Shultz <email@hidden>
- Date: Wed, 08 Feb 2012 21:46:43 -0800
On 2/8/12 6:26 PM, G S wrote:
>>
>>> It's just a crash in the control's dealloc method:
>>> 0x0019f56e -[ThumbStripView dealloc]
>>
>> But what is the crash? EXC_BAD_ACCESS?
>>
>
> Don't know. The above is all that appears in the crash log, and it's so
> hard to reproduce that I've never seen it while running under the debugger.
Ah. If it's non-deterministic, this further increases my suspicion that
there is a problem elsewhere in your code.
> If so, I wonder whether this is just a symptom of an elusive
>> over-release elsewhere in your code. Does anything show up in Clang?
>> Have you tried running with zombies enabled?
>>
>
> Well, at the time the owning view is deallocated (because yes, it is
> deallocated; I've stepped through it), the control isn't. And although I
> know retainCount isn't reliable, it's 3 at the point of the parent view's
> deallocation. So I don't see how over-releasing could be a problem, since
> the only entity that would even attempt to release it in my code has been
> blown away.
You are getting a crash. Crashes don't happen because of over-retains
(save for forced termination if you get too huge a memory footprint, but
that will show up as a distinct flavor of crash).
Over-releasing can and will cause crashes.
Are there *any* connections to your control (other than the
superview/subview relationship)? I see a _NSSetObjectValueForKeyInIvar
in your retain trace, which just be doing something internal, but it
makes me wonder.
> I've never used Clang. I ran the app in Instruments looking for leaks and
> with zombies enabled. No zombies found, and I've fixed the few leaks that
> existed.
The Clang static analyzer is the backend for the Analyze action (or
Build and Analyze in Xcode 3). If you haven't run your code through it,
you should. I prefer to run it constantly and not continue any
development until I have eliminated any warnings that Clang issues (or,
rarely, have satisfied myself that my code is doing something peculiar
for a very good, well-understood reason).
Clang is extremely good at finding memory management errors, which I
still suspect is the problem here.
> I had read that Apple doc on IBOutlet management, thanks. Looking at it
> again, however, I see that I overlooked this:
> "To ensure that you properly relinquish ownership of outlets, in your
> custom view controller class you can implement viewDidUnload to invoke your
> accessor methods to set outlets to nil."
>
> I'm going to give that a try.
That may be helpful, but refrain from just trying things until something
works. There is something deeper going on here, and I will almost 100%
guarantee you that just setting some things to nil will not fix the
problem or, worse, will cover it up. (The only exception, as alluded to
earlier, is nilling out delegates, which you *definitely should* do.)
--
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
_______________________________________________
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