Re: debugging strategy
Re: debugging strategy
- Subject: Re: debugging strategy
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 16 Sep 2009 19:47:13 -0700
Here is the situation. We have a large application that has been in
the field for several years now. We are adding new feature for our
next release, and we are testing the new builds against Snow Leopard
as well as earlier versions of OS X. Under Snow Leopard, some
existing functionality has stopped working in a mysterious way. It
is crashing deep inside webkit, but the initial symptom is that the -
drain method is invoked on a object other than an autoreleasepool.
The class of the object on which -drain is being invoked varies with
the run. Obviously, we are not calling -drain deliberately, and I
doubt that webkit is either, so something is getting screwed up.
So, it seems like memory somewhere is getting corrupted, but where?
We are also unable to breakpoint in some of the webkit delegate
methods, so I suspect the corruption is in the stack. But I do not
know any good ways of finding stack corruption.
Does the theory of stack corruption seem plausible? Other ideas?
And how can one go about searching for a problem like this?
Most likely it's a dangling pointer, most likely because of an over or
early release.
First stop should be the 'Zombies' template in Instruments, in Snow
Leopard. Run your app via it, cause the error, and it should jump
straight to the object that's missing.
If it doesn't, and you still get -drain sent to a random object, then
you might consider memory smashing. But I wouldn't try to go down
that route unless you have to, as memory smashers are hard enough to
prove let alone debug.
Wade
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden