Re: ObjectAlloc tool and framework debugging
Re: ObjectAlloc tool and framework debugging
- Subject: Re: ObjectAlloc tool and framework debugging
- From: j o a r <email@hidden>
- Date: Fri, 24 Nov 2006 07:48:20 +0100
On 24 nov 2006, at 03.12, Skip Haughay wrote:
I am attempting to use the ObjectAlloc tool to track down some
memory leaks. From within XCode, in the framework project, I
select the option to run using the ObjectAlloc tool. Everything
starts up just fine, and I work the portion of the code which
generates the leak. I set the tool up to flag retain/release
behavior as well as backtraces. Now the problem... When I LOOK at
the backtraces from within ObjectAlloc, I see method entry points
for stuff in the host Cocoa app, but once it dips into the
framework code, I get addresses rather than entry point names.
File a bug report!
I could just use gdb to resolve the entry point names, but in many
cases of these leaks, we are talking call stacks of some 40 items
deep, due to the recursive nature of the code being executed. It
would be a monumental task to have to wade through each and every
one of these, for each and every retain/release action. So my
question is, how in the world do I get this to show meaningful call
stack information?
Off-list I mentioned using the command line utility "atos" to make
that process a bit more efficient. Didn't it work? It should!
I also have some questions about how ObjectAlloc works. When it
works, I see AllocateEvents, RetainEvents, ReleaseEvents,
AutoreleaseEvents, and Dealloc Events. When I look at the
inspector, I assume that I can click on each of these events for a
particular memory object, and see the call stack as to where that
particular event was invoked. Am I right about that?
Yes. It's incredibly powerful. If you have a fully reproducible way
to trigger the leak, and can catch it while running in ObjectAlloc,
there really is no way for it to avoid discovery.
Also, I am curious about what causes the retain and release
events... Obviously a call to retain and release will do this. BUT
does the initial Alloc generate an allocate event AND a retain
event to get the initial reference count of one? Or is the
reference count just set to one by the Alloc event?
It's set when the object is allocated, not by a call to retain.
Is the autorelease event registered in ObjectAlloc when the
autorelease method is invoked, or is it registered when the pool is
cleared? OR does the autorelease event happen when autorelease is
invoked, and then when the pool clears, a subsequent release event
is registered?
When recording backtraces to specific memory management events, they
better be recorded when they actually happens, and not some time
later. Consequently, the autorelease event is registered when the
call to autorelease is made. When objects are sent a release message,
as a result of popping an autorelease pool, "regular" release events
are registered.
If this is the case, is there any way I can tell that this release
event was caused by an autorelease action from the pool clearing?
From the backtrace!
This leak is really proving to be a bear to debug, because of the
level of complexity due to the recursion, and the sheer number of
data fields being parsed in my code. For a specific class of data
fields and chain of events, I either have too few releases, or too
many retains.
Just decode one of the backtraces already...
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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