Re: More autorelease pool strangeness
Re: More autorelease pool strangeness
- Subject: Re: More autorelease pool strangeness
- From: Skip Haughay <email@hidden>
- Date: Mon, 20 Nov 2006 10:37:30 -0500
The framework is one which I am maintaining. The items ARE added to
the autorelease pool at creation. Just prior to [thePool release],
it appears that these items are at retainCount of 1. Releasing the
pool SHOULD decrement all contained items by one, thus putting these
items at retainCount of 0 and dumping them. It doesn't appear to be
happening. I am never getting the -dealloc method called on these
objects despite apparently correct usage. BUT if I allocate one of
these things without autorelease... and release, no problem, I get
the dealloc called.
It is really strange. Aren't there situations in which a dealloc
won't be called, say at application termination... since the memory
zone is dumped, Objective-C doesn't waste its time dumping each
individual item? Is there some similar wierdness with frameworks?
Also, with a framework, do they allocate memory in the application's
zone, or do they have their own?
Skip
On Nov 20, 2006, at 10:23 AM, Alan Smith wrote:
But this I do know. Autorelease pools only release objects that have
been sent the autorelease message or have in some other way added to
the current autorelease pool. In other words, sending an object the
release message will not put it in a pool.
If retain count is still at 1 than it hasn't gotten enough release
messages but, retainCount should not be relied on. I suggest looking
through the code in the framework to make sure the alloc message and
retain messages are all balanced with a release message. If you can't
look through the code, and you didn't originally write the code, send
the dev a bug report.
Disclaimer: I may be wrong on this and if I am, don't bash me.
Good luck, Alan
On 11/20/06, Skip Haughay <email@hidden> wrote:
I am having a real problem finding a memory leak in a framework.
I need some suggestions on how to find this thing.
An application calls loads this framework and calls an entry-point
function within:
resultType EntryPoint
{
NSAutoreleasePool *thePool;
thePool = [[NSAutoreleasePool alloc] init];
// Function calls to do the work - problematic allocation
is made in one of the called functions.
[thePool release];
}
There is one particular object type that is allocated in the
called functions, which contains a couple of NSArray fields. This
object is autoreleased by its factory method, and the parent
object retains it. As the program executes, several other data
structures may retain this item. I overrode the release/retain
items in the object of interest in order to display via NSLog the
current retainCount of the objects of interest.
Anyway, on the last series of releases of objects of this type,
the retainCount is 1. The code then comes to [thePool release]
which should, in theory, decrement the retainCount on any listed
item, allowing the runtime to clean things up. This does not seem
to happen... the dealloc is never called for these objects, as
[thePool release] is called, and control goes from the framework
back to the calling application.
When I subsequently examine the process of itnerest using the
"leaks" command-line call, I see that this object of interest is
showing up as leaked. Any ideas as to what would cause this?
Any ideas on how to debug this, or what could cause this odd
behavior?
Skip Haughay
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
--
// Quotes from yours truly -------------------------
"You don't forget, you just don't remember."
"Maturity resides in the mind."
"Silence is the Universe's greatest gift."
"When the World realizes that religion really is unnecessary, then it
shall evolve."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden