Re: AU - CW code gen problems
Re: AU - CW code gen problems
- Subject: Re: AU - CW code gen problems
- From: Marc Poirier <email@hidden>
- Date: Sat, 29 Mar 2003 07:22:38 +0100 (CET)
Hi. Having started this thread and not having explained things too well,
first I want to explain a little bit.
The project that I posted doesn't do anything in particular. It's a
completely skeletal plugin that does nothing but derive from the AUPublic
SDK classes and specify that a custom UI exists (albeit a UI that
displays nothing). There's no audio, nothing in the view, etc.
The point is that, even though the plugin does nothing beyond the SDK
stuff, it crashes. Badly. But only when built with CW. My conclusion
was that this meant that either the SDK has a bug or CW is goofing up. At
this point, I'm really leaning towards the SDK being at fault.
More specifically, this is where the crash seems to occur:
CarbonEventHandler.cpp, line 48, in TheEventHandler:
if (handler->HandleEvent(inEvent))
The crash occurs upon destroying the view, when the kEventClassWindow,
kEventWindowClose event is received. The reason why the crash occurs is
because, at that point, the pointer which is passed in as inUserData and
cast to CarbonEventHandler *handler is bogus. My opinion is that this
unfortunately is only a symptom of the bug, not the bug itself. The bug
itself is most likely a "memory stomper" where the memory where that
pointer lives got written over at some point.
I have no idea where that memory corruption occurs. I very much
appreciate the tips that people are posting with respect to debugging this
problem, and I don't mean to sound ungrateful when I say this, but
unfortunately I'm on an extremely tight work schedule right now and I just
don't have time at the moment to dig into more bugs, ones which aren't in
code that I wrote. I'm really hoping that some folks on the CoreAudio
team at Apple might have access to CW and could try to find the bug and
fix it. I don't mean to be shuffling this off, but so far as I can tell,
the bug is in Apple's code so I hope that Apple can fix it. I'm just
really overloaded at the moment, otherwise I'd put time into trying to
fix it. I've uploaded a skeleton project that is as simple as possible,
already configured and ready to go, which hopefully can make it a little
easier for someone else to get started finding and fixing the bug. So
hopefully that can be of some use.
If any progress is made with respect to solving this bug, I (and I'm sure
everyone on the list) would love to hear.
Thanks for all of the help,
Marc
On Fri, 28 Mar 2003, 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.