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: Jeff Moore <email@hidden>
- Date: Tue, 9 Aug 2005 11:50:36 -0700
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. :)
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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