Re: My bug or Apple's?

FROM : John Stiles
DATE : Sat Nov 20 07:32:13 2004

On Nov 19, 2004, at 3:18 PM, John C. Randolph wrote:

> On Nov 19, 2004, at 3:04 PM, John Stiles wrote:
>

>> Well, as a matter of course, I try to release everything I allocate.
>> At my work, our allocator code will complain about a memory leak if I
>> don't.
>>
>> In this particular case, TSHashTables destroy each of their elements
>> when they are destroyed, because that's how they were designed.
>> Usually it's helpful. :)
>>
>> If I just wanted to leak the images, I could make my Image class'
>> destructor do nothing, but that seems like an error to me. Yes, in
>> this particular instance we're quitting anyway, so we don't HAVE to
>> free. But should I really need to make two separate types of Image
>> objects--one that frees itself on destruction, and one that
>> doesn't--just because of this bug? It doesn't seem logical to me.

>
> Well, freeing individual objects when quitting an app serves no
> purpose, and just makes your app take longer to exit.


My app doesn't take a long time to exit--it's basically
instantaneous--and our policy at my job is to clean up all your
allocations. (a) It's not my place to challenge that policy, and (b) I
think it enforces good programming practices. If we were taking a long
time to shut down, then I'd look at ways to speed it up, probably by
putting all my allocations into a pool or zone or something.

> The problem you're hitting here is that you're using Cocoa objects
> after the framework has finished its
> normal shutdown procedure:  that's why there's no autorelease pool in
> place.
>
> I'd say your best bet is to set a global "isTerminating" flag when the
> user quits, and have your destructors check that flag and do nothing
> if it's set.


Is there anything wrong with just making an autorelease pool around the
[myImage release]? That's a less invasive solution and seems to have
solved the problem I was having.