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 14:39:27 -0700
Scott Ribe <mailto:email@hidden> wrote (Tuesday,
November 16, 2010 10:32 AM -0700):
On Nov 16, 2010, at 9:25 AM, James Bucanek wrote:
The memory block it tries to release is invalid (was never allocated).
FYI, I've had the tools give me a message about freeing a block that was never
allocated when I double-freed an allocated block. So it doesn't actually mean
that no block was ever allocated with that address, just that there's not
currently a block allocated with that address.
<clip>
Scott,
All very good points, but in this case I think the malloc
library is actually correct (shocking, I know).
Because I ran malloc_history I was able to search the history of
allocs/frees, and the address the failure complains about never
appears in the history. I did find an earlier NSObject malloc (I
have no idea what the actual object class is) that had not been
released yet. That alloc encompasses the bad address passed to
free(). I have no idea if the two are related (i.e an an NSData
created to an internal structure of another object), or if it's
purely coincidence.
Are you in control of the allocation of all these NSData objects? My
understanding is that swizzling is more or less gone, but could you create a
simple subclass that overrides retain & release with your own logging versions
and use that in place of NSData? Of course if you disturb memory layout much,
you may just mask the problem, but it would be worth a try.
Another excellent suggestion. When I started this, I was sure it
was one of my NSData objects, but now I'm convinced it's not.
(Note: merely stating this will undoubtedly incur the wrath of
the coding Gods--who hate arrogant programmers--and just for
that, I'll surely be proven wrong.)
I actually started out with a similar approach, logging the
NSData objects I create in that part of the program, their
addresses, the objects that own them, and what not, to the log.
But I never found an NSData object that corresponded to the one
that's causing the crash.
No I can only assume it's an NSData object allocated by the
framework or something buried in my code that I cant find.
A problem with creating an NSData subclass is that, as far as I
know, NSData is class cluster. So creating and using a private
subclass instead might not accomplish anything, other than to
change the behavior of the problem.
One thing I might try is some "legal" swizzling: I believe you
can use method_setImplementation to replace the function for a
method at runtime for an entire class. If so, then I could
"hook" the dealloc method in NSConcreteData and do my debugging there.
An extremely crude debugging technique when all else fails, provided you won't
run of memory, is to selectively eliminate release/free where you suspect you
might have a over-release or double-free, and see whether or not it still
crashes.
That's a great idea, at least for narrowing the problem down. If
added some auto-release pools at strategic points in the code,
at least I could bracket the source of the problem.
Thanks,
James
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