Re: More autorelease pool strangeness
Re: More autorelease pool strangeness
- Subject: Re: More autorelease pool strangeness
- From: "Alan Smith" <email@hidden>
- Date: Mon, 20 Nov 2006 10:23:22 -0500
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:
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