Re: How 'reliable' is MallocCheckHeap et al ?
Re: How 'reliable' is MallocCheckHeap et al ?
- Subject: Re: How 'reliable' is MallocCheckHeap et al ?
- From: Andrew Kimpton <email@hidden>
- Date: Sun, 26 Sep 2004 16:32:33 -0700
Eric Albert wrote:
On Sep 24, 2004, at 8:36 PM, Andrew Kimpton wrote:
Eric Albert wrote:
On Sep 24, 2004, at 11:07 AM, Andrew Kimpton wrote:
I'm struggling to chase down what at first glance should be a
relatively simple memory smashing bug.
I'm using the MallocDebug environment variables :
Have you tried using Guard Malloc? It catches memory smashers very
effectively and pinpoints the exact place of the fault. (It also
causes your application to run about 100x slower than normal, but
that's worth it when you catch a memory smasher as a result.)
Ultimately GuardMalloc did find this bug - where MallocDebug was (sadly)
no help at all. Here's how and what was wrong :
The problem turned out to be an undersized area of memory being passed
to pthread_mutex_init(). I was able to work this out by placing a break
on pthread_mutex_init() and noticing that gdb would give an 'unable to
access memory' error after displaying only 20 bytes of data of the first
argument. Since the pthread_mutex_t structure is supposed to be 44 bytes
long this would seem to be the source of my problems.
Breaking on malloc confirmed that it was only allocating 20 bytes or so
for the class containing the structure. This lead me to examine in close
detail the boost headers to see if I had a class allocated one way but
initialized another. This was indeed the problem. ConditionalMacros.h
was in the header list for a particular file ahead of the boost headers,
which lead to TARGET_CARBON being 1. That in turn lead boost to NOT use
pthreads (no pthreads on carbon) and thus create a different class from
the one actually being initialzed.
As Kon & Bal would have said in the old puzzle pages "Sneaky".
Making sure that the headers were set up correctly caused the problem to
be resolved - yippee !
I have to repeat that GuardMalloc was much better here than either of
the other options. I wonder if the restrictions about altivec
instructions will be removed some time soon (would be nice - this app
uses them so if I have a problem deeper into the app I'm SOL using
GuardMalloc)
Thanks Eric for your help !
Andrew 8-)
P.S. I miss those old Kon & Bal puzzle pages, at least (I think) they're
archived on the Mac Tech site.
_______________________________________________
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