Re: How exactly are we supposed to debug memory problems???
Re: How exactly are we supposed to debug memory problems???
- Subject: Re: How exactly are we supposed to debug memory problems???
- From: "Andy O'Meara" <email@hidden>
- Date: Thu, 17 Aug 2006 10:21:09 -0400
- Thread-topic: How exactly are we supposed to debug memory problems???
You didn't mention the scope/size of your codebase, but you may want to
change all your malloc() and free() calls to your own function (kb_malloc(),
kb_free() -- killerbytes, right?) that you therefore can tightly control.
In your debug builds, for example, could actually define functions
kb_malloc() and kb_free() and do your own customized tracking. In this
case, if you knew that your double free is happening for sizes of, say 1234,
you could actually insert logic that would only do tallying/bookkeeping for
block requests 1100 to 1300. In your release builds, you can just make them
macros for malloc() and free().
Aside from debugging, it's always useful to have allocation abstraction like
this in place so that you can do things like easily use an alternate
heap--who knows where you code may end up--in an embedded system that
perhaps only has a fixed block of memory that you have to manage (extreme, I
know, but you get the point).
Andy
On 8/17/06 12:45 AM, "Scott Ribe" <email@hidden> wrote:
> I've got a double free. MallocBadFreeAbort doesn't abort. Setting a break in
> szone_error doesn't do anything either. Setting a break in malloc_printf
> does work, but that's mostly useless to me because I also need to use
> MallocCheckHeapStart & Each.
>
> XCode 2.4, OS X 10.4.7.
_______________________________________________
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