Re: AU - CW code gen problems
Re: AU - CW code gen problems
- Subject: Re: AU - CW code gen problems
- From: Chris Thomas <email@hidden>
- Date: Fri, 28 Mar 2003 20:15:00 -0800
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.