Re: Setting a breakpoint on malloc_printf
Re: Setting a breakpoint on malloc_printf
- Subject: Re: Setting a breakpoint on malloc_printf
- From: Jim Ingham <email@hidden>
- Date: Tue, 24 Feb 2004 10:25:56 -0800
On Feb 24, 2004, at 8:20 AM, Justin Greenfield wrote:
I've got a terribly insidious memory smashing bug in a multi-threaded
app that I am trying to track down. I have been beating my head on
this for much, much too long now. I am beyond desperate and I my
progress has slowed to a crawl.
From the MallocDebug help:
Tracking down stale pointers and writes to freed memory
The second example -- holding on to an out of date pointer -- can
also be detected using MallocDebug. MallocDebug finds writes to freed
memory by erasing memory when it is freed, overwriting the contents
of the buffer with the hexadecimal value 0x55. MallocDebug then
watches for changes to that memory on each call to free. When it
finds memory has been smashed, it prints a warning to the console:
MallocDebug: target application recently wrote to freed malloc'd
memory at: 0x194f808, suggesting it didn't realize the memory had
been freed
This shows that a memory smasher exists; by putting a break point on
malloc_printf, the function that prints the error, you can find what
point in your code might be near the smash.
My problem is, I absolutely cannot cause a breakpoint to fire on
malloc_printf when I get these errors printed. I am on 10.3 using
xcode 1.1. I tried going to the breakpoints window, clicking "New
breakpoint" and entering "malloc_printf" but it never fires. I
started gdb in a terminal window and tried "fb malloc_printf" and it
never fires.
If anybody has the slightest idea what to do differently to find this
bug, I would be eternally grateful. I have run out of ideas and
options.
One thing that might be going on: when you do DYLD_INSERT_LIBRARIES to
add the libMallocDebug.A.dylib to your program, you now have two copies
of malloc_printf in your program, the one from the original malloc in
libSystem, and the one from libMallocDebug. If you also set
DYLD_FORCE_FLAT_NAMESPACE to 1 (if you use the MallocDebug app it will
do this for you) then dyld will fix up all the references to
malloc_printf so that they point to the new one from libMallocDebug.
But it is possible that gdb is still finding the libSystem one and
putting its breakpoint there. You can find this by doing:
(gdb) break malloc_printf
Breakpoint 1 at 0x8dde3760
(gdb) info sharedlibrary 0x8dde3760
3 libMallocDebug.A.dylib - 0x8dde0000 dyld Y Y
/usr/lib/libMallocDebug.A.dylib at 0x8dde0000 (offset 0x0)
That's what you want to see, if you see it coming from libSystem
instead, then you that would explain why you weren't hitting the
breakpoint. In general, if you set a breakpoint but it is not firing
when you think it should, you should check the address that the
breakpoint got set at - either by looking at the address that was
printed when it was set, or by looking afterwards with the "info break"
command. Then using "info sharedlibrary <ADDRESS>" to make sure that
it is set where you expected. Another useful command in this
circumstance is "info func", which will tell you where all the
instances of the symbol are:
(gdb) info func malloc_printf
All functions matching regular expression "malloc_printf":
Non-debugging symbols:
0x8dde3748 malloc_printf
0x8fe20ed0 __dyld_malloc_printf
0x9009e380 malloc_printf
0x900fe644 dyld_stub_malloc_printf
which indeed shows that we have two copies of malloc_printf...
In any case, you can force gdb to break on a symbol in a particular
library if you are using the XcodeUpdate version of gdb by doing:
(gdb) interpreter-exec mi "-break-insert -s libMallocDebug.A.dylib
malloc_printf"
Sorry for the ugliness of the command, it is primarily for the
gdb/Xcode communication (that's what the "mi" bit is about), and we
haven't come up with a good command line interface for it yet. But
this will make sure that the breakpoint gets set on the libMallocDebug
version of malloc_printf.
Maybe this will help...
Jim
--
Jim Ingham email@hidden
Developer Tools
Apple Computer
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.