Re: linking with CoreAudio produces run-time crash
Re: linking with CoreAudio produces run-time crash
- Subject: Re: linking with CoreAudio produces run-time crash
- From: Heath Raftery <email@hidden>
- Date: Wed, 10 Aug 2005 17:38:34 +1000
In case the OP is not still around, allow me to follow this up. We
spoke via IRC and the OP appears to have the original issue sorted
out. I believe it turned out to be an errant pointer earlier in the
code making a mess of memory, and causing a crash elsewhere. The
apparent trigger - linking to the CA framework - appeared to serve
only to shuffle things around in memory sufficiently enough to put
critical code in the path of the errant pointer.
Heath
On 10/08/2005, at 4:50 AM, Jeff Moore wrote:
It sounds like you have some link issues. Are you using Xcode to
build your project, or are you doing it on the command line? Seems
like the latter. If so, can you post the gcc command line you are
using?
BTW, one of the developer tools oriented lists might be able to
help out too since the problem seems to be a build issue as opposed
to an API usage issue.
On Aug 7, 2005, at 2:14 AM, paul wrote:
Hey all,
I'm working on a simple command-line utility that streams a
file from disk(libsndfile) thru a data structure for processing
and then on to the AUHAL for playback. Unfortunately, I'm
encountering a very strange run-time "issue" which causes the
program to crash if I so much as link with the coreaudio
frameworks. The code can be literally the same(all coreaudio
stuff commented out) in both cases but nonetheless, one crashes,
the other does not.
Here are my linker flags in each case(using Tiger && gcc 4.0):
stable: -lsndfile
crash: -lsndfile -framework CoreServices -framework
CoreAudio -framework AudioUnit
Here's the gdb report:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x3caa8000
0x8fe036a0 in __dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm ()
(gdb) bt
#0 0x8fe036a0 in
__dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm ()
#1 0x8fe165f8 in __dyld_stub_binding_helper_interface ()
#2 0x00002c68 in PlayFile (file_name=0xbffffc12 "Balkan.aif") at
sundry.cpp:68
#3 0x000030ac in main (argc=3, argv=0xbffffb5c) at main.cpp:40
PlayFile(), despite it's name, has all the coreaudio code
commented out of it and is only concerned with filling up data
structures.
(gdb) f 2
#2 0x00002c68 in PlayFile (file_name=0xbffffc12 "Balkan.aif") at
sundry.cpp:68
68 pthread_mutex_lock( &SkelKey ); //lock it
Here you can see that the linker appears to be choking on the
pthread_mutex_lock() call. It dies in the dyld_stub before ever
resolving the symbol. Interestingly, this is well before the
stage where any(now commented out) audio code would be executed.
I'm an utterly confused and would appreciate any suggestions/
ideas. :)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden