Re: Help DTrace gurus: suggestions for capturing a mis-allocated NSData object on a customer's system
Re: Help DTrace gurus: suggestions for capturing a mis-allocated NSData object on a customer's system
- Subject: Re: Help DTrace gurus: suggestions for capturing a mis-allocated NSData object on a customer's system
- From: James Bucanek <email@hidden>
- Date: Tue, 16 Nov 2010 09:25:20 -0700
Hello again,
I'm back, and I'm still unable to debug my customer's problem.
I'm trying desperately to identify the creator of an NSData
object in an application that's crashing.
To recap, I make a backup application and I have one customer
who is experiencing a persistent and repeatable crash. But after
dozens of attempts, I have had no success in reproducing the
problem here. I have also tried repeatedly to send him versions
of the application designed to find/fix/capture the problem, to
no avail. The problem only occurs with a handful of files (in a
single directory) on this customer's system. I'd just say "hey,
delete those files" but I've seen this crash from another
customer (once, not repeatable). So I'm sure it's happening
elsewhere, and I'm really keen to track this down.
The problem is this: During the execution of a helper process,
an NSData object is created and autoreleased. Later, the
autorelease pool is drained, the NSData (actually
NSConcreteData) object is released, it attempts to release its
malloc block, and the application crashes. The memory block it
tries to release is invalid (was never allocated).
One list member suggested I try malloc_history. So I created a
version of the program that launches the subprocess with the
various MallocStackLogging environment variables set. The helper
process traps the SIGABRT (and other crashy) signals. When the
process crashes, it runs the malloc_history tool before terminating.
With this information, I was able to determine what I already
knew, but not much more. The address the NSConcreteData is
trying to release was never allocated (but appears that it might
be inside another object allocation). None of the registers
contained the address of any allocated object, so I have no idea
what NSData object is calling free().
Looking back through the malloc history, there are *hundreds* of
allocated NSData objects, any one of which could be the culprit.
So I'm back to my original question: Is is possible to write a
DTrace script (or use some other tool) to trace the allocation
and deallocation of every NSData object in a helper process
started by another application, in a way that I can deploy this
test so my customer can run it themselves? The customer has
Xcode 3.2.4 installed.
Any and all suggestions are welcome.
James Bucanek
____________________________________________________________________
Author of Professional Xcode 3 ISBN: 9780470525227
<http://www.proxcode3.com/>
and Learn Objective-C for Java Developers ISBN: 9781430223696
<http://objectivec4java.com/>
_______________________________________________
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