Debugging Malloc problems
Debugging Malloc problems
- Subject: Debugging Malloc problems
- From: Bill Stewart <email@hidden>
- Date: Sat, 29 Mar 2003 11:25:04 -0800
In fact there is something else with malloc debug that you should be
aware of (and I also prefer to use the env variables approach that
Chris outlines)
MallocDebug does NOT allocate buffers that are guaranteed to be altivec
aligned (unlike malloc which does guarantee that)... We've been bitten
by this a couple of times in the past when using it with our audio unit
code because it makes the "correct" assumption that malloc'd buffers
are altivec aligned... If we've gone to the case of using malloc debug,
we disable altivec code (and hope that that isn't the code causing the
problem:)...
Bill
On Friday, March 28, 2003, at 08:15 PM, Chris Thomas wrote:
On Friday, March 28, 2003, at 11:29 AM, Stephen Davis wrote:
On Friday, March 28, 2003, at 07:38 AM, Marc Poirier wrote:
I did not compiled an AU with CW8 (I mean before your test project),
but I do use CodeWarrior (OS X Dev Studio) for my professional
development. I work on a C++ library which implements the CORBA
runtime
(CORBA is a standard distributed middleware). I can say you that CW8
generates a high quality code. Of course, I experiment crashes
sometimes, but they always are the result of design or coding
errors.
Yeah, I'm now thinking more and more that the problem is not with bad
codegen (I also have never had such problems with CW 8 since it was
released) but most likely a bug in the AUCarbonViewBase SDK code
that is
only materializing when built with CW or a bug resulting from my
project
configuration (most likely from some incorrect includes, although I
would
be a bit surprised if that caused such major damage, but it is
possible).
Going back to the memory stomper possibility, CW and gcc definitely
lay out memory differently so memory stompers built with gcc may end
up being okay whereas the same code built with CW will crash (and
vice versa) b/c different things are getting stomped. This most
often occurs when the thing being stomped is on the stack.
One suggestion might be to run the hosting app with MallocDebug which
has some rudimentary stomper catching. It will log a message to the
Console if it detects a stomper but unfortunately won't tell you
where it is. It also might not detect one that does exist which
means you shouldn't assume there isn't a stomper if you don't see any
messages -- it's abilities to catch such things are limited but you
should at least try it.
For suspected memory smashers, I'd recommend starting with the malloc
environment variables instead of MallocDebug:
MallocStackLogging causes malloc to remember the caller requesting
each allocation.
MallocStackLoggingNoCompact causes malloc to remember the caller
requesting each allocation, and remembers it after the allocation is
freed.
MallocScribble to detects writes to a freed block by clearing its
contents
MallocGuardEdges add guard pages before and after large allocations
MallocDoNotProtectPrelude: disables the guard page before block
MallocDoNotProtectPostlude disables the guard page after block
MallocCheckHeapStart checks the heap's internal data structures at
intervals.
MallocCheckHeapEach checks the heap's internal data structures at
intervals.
See /Developer/Documentation/ReleaseNotes/MallocOptions.html for full
docs.
Chris
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.