Re: Any useful information in this output from malloc_history?
Re: Any useful information in this output from malloc_history?
- Subject: Re: Any useful information in this output from malloc_history?
- From: Ken Thomases <email@hidden>
- Date: Sun, 14 Sep 2008 21:26:20 -0500
Hmm. Well, I'll answer the easy bit first:
On Sep 14, 2008, at 7:42 PM, Jerry Krinock wrote:
The man page for malloc_history does not say how to read its
output. Does the number in square brackets after "Call" tell me
anything useful? How about the [arg=...]?
Unfortunately, neither of those values are especially valuable. The
number in brackets after Call just indicates what type of event it was
(alloc, free, etc.). See the constants defined at the top of this file:
http://www.opensource.apple.com/darwinsource/10.5.4/Libc-498.1.1/gen/stack_logging.h
I believe the arg is, for allocations, the size requested.
I assume that the pipe (|) characters delimit the symbols on the
call "stack".
Yep.
On Sep 14, 2008, at 7:42 PM, Jerry Krinock wrote:
I have one of those bugs I've read about that cause the application
to crash at some unpredictable time after certain events have
occurred.
So I followed all the advice on NSZombie, malloc debugging, etc.
Also, I set a breakpoint in Xcode's Breakpoints window at
"malloc_error_break", and checked the box. Later I noticed Xcode
had filled in its "Location" is "libSystem.B.dylib", so that seems
like it probably worked.
With all these guns loaded, reproducing the crash, sometimes I get
100 or so malloc messages logged, sometimes none, sometimes one.
When I get 100 or more, malloc_history gives me a blank line for
most of them. Let's consider a trial when I got one "live" one...
malloc: *** error for object 0x16f42770: incorrect checksum for
freed object - object was probably modified after being freed.
So I invoked malloc_history and got the result below [1]. It looks
like to me like 0x16f42770 got had four "malloc events" before the
crash:
alloc, within NSLog(), duplicating a string with strdup()
free, within NSLog(). Balances the alloc, as expected, I suppose.
alloc, within -[HtmlTypeStore
browserXMLClauseFromBmItem:indentLevel:fileProperties:fixture:]
alloc, within NSLog()
So, it looks like maybe this area of memory was used once, by
NSLog(), freed, and then used twice again. The fourth event might
be an undesired over-write but then that might be OK the third event
was a temporary variable that had gone out of scope?
Honestly, I don't know what it might mean that there are two
allocation events in a row. That shouldn't happen. It doesn't have
anything to do with a temporary variable going out of scope.
I've personally encountered a rare case where malloc logging fails to
interpret the stack trace. In that case, malloc_history just fails to
show the event. That might account for the apparently missing free
between events 3 and 4. My rare case had to do with code which used
assembly language to switch which stack area was being used, so it's
unlikely to be something encountered by any normal application. In
any case, the Object Alloc instrument at least showed the event,
albeit with an empty stack trace. So, that's a bit more reliable.
You don't say precisely which malloc debugging tools you've already
tried. Given that something appears to be overwriting freed memory,
I'd definitely enable scribbling (MallocScribble=1). Next, I'd try
MallocGuardEdges. You can also use MallocCheckHeapStart and related
variables to try to force the corruption to be detected closer in time
to the cause.
The big gun is Guard Malloc, although it's cumbersome enough that it's
sometimes not viable. See man libgmalloc.
Another thing to think about: if you're overwriting a freed block,
that may be because you're overrunning a block that comes before it in
memory. So, looking at the malloc history of the corrupted block may
be looking in the wrong place. malloc_history isn't great for
searching for blocks that were positioned "somewhere" before the block
in question. The Object Alloc instrument is better for that. The
diagram view can be sorted by object address so you can view the
history of whatever blocks were just before the one that got corrupted.
Good luck,
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