Re: Breakpoint in malloc?
Re: Breakpoint in malloc?
- Subject: Re: Breakpoint in malloc?
- From: Jim Wintermyre <email@hidden>
- Date: Wed, 22 Apr 2009 17:23:22 -0700
Thanks, Malloc Trace in Shark was just the ticket (duh!).
Jim
At 9:52 PM -0500 4/21/09, Ken Thomases wrote:
On Apr 21, 2009, at 9:14 PM, Jim Wintermyre wrote:
I'm trying to diagnose an unexpected memory allocation that is
happening when I don't think there should be any memory allocation
going on. Is there a way to set a breakpoint in whatever the
standard allocator is that's called by malloc and new?
Malloc is the standard allocator. I believe new uses malloc. Of
course, you mustn't forget about malloc's friends like calloc,
realloc, etc.
It's opensource, so you can see exactly how it's implemented:
http://www.opensource.apple.com/darwinsource/10.5.6/Libc-498.1.5/gen/malloc.c
Even if there were an underlying allocator behind malloc, you
wouldn't want to put your breakpoint there. The overlying malloc
would surely manage/cache what it would get back from such an
allocator, thus not invoking the low-level allocator for every
invocation of malloc. So, you wouldn't catch every call to malloc
by putting a breakpoint in the lower-level allocator.
I've tried using MallocDebug in the Mark/Update mode, and it does
show the memory allocations, but for some reason it is showing the
call trace in hex instead of using the symbols.
You mean the old MallocDebug application? You should probably be
using Instruments and the Object Allocations tool, instead.
I think this is because my code is in a shared library (I saw an
old post in the archives where someone else had the same problem
with a shared library). Getting the stack trace out of the raw hex
is kind of a pain. So any suggestions on getting that to work are
also appreciated (my debug symbols are definitely present; they
show up in Shark and other performance tools).
Well, the 'atos' command-line tool is the usual way, but maybe
that's what you are referring to as "kind of a pain".
Since you're familiar with Shark, you can try its Malloc Trace, too.
You can also trace the allocation functions using DTrace:
sudo dtrace -n 'pid$target:libSystem:[mvc]alloc:entry,
pid$target:libSystem:realloc*:entry {ustack();}' -p <pid>
Or, you can use '-c <command>' instead of '-p <pid>'.
Cheers,
Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden