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: Chris McKinnon <email@hidden>
- Date: Tue, 09 Aug 2005 20:54:52 -0600
Hi
I had a similar issue with a Cocoa/CoreAudio app that I'm writing. I
would get a runtime error when my CoreAudio code, that was in a C
source file, was called. The error was ZeroLink complaining about a
missing symbol. I tried everything I could think of to fix it,
assuming I had done something wrong. In the end what fixed it for me
was changing the .c extension on my C source file to .cpp. I gave the
Cocoa source file a .mm extension because I'm planning on programming
most of it in C++. I'm running XCode 1.5, Mac OS 10.3.9, with the
latest CoreAudio SDK.
Strange,
Chris McKinnon
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