Re: Weird CloseComponent Crash
Re: Weird CloseComponent Crash
- Subject: Re: Weird CloseComponent Crash
- From: Stephen Davis <email@hidden>
- Date: Tue, 23 Jan 2007 11:15:48 -0800
On Jan 23, 2007, at 9:18 AM, Norman Franke wrote:
I randomly get a crash when calling CloseComponent on the HAL
output I opened with OpenAComponent. Often it happens the first
time I call it.
It dies in different places inside CloseComponent, but always in
szone_free. Up one level it can be things like
~BufferedAudioConverter's call to operator delete[], or
Resampler2Wrapper's call to ReleaseSincKernel.
Crashing in szone_free() is a very good indicator that you've
corrupted your heap (specifically, you've stomped on the free list by
writing into the memory of a buffer you've already freed).
Just now I got the same crash in AudioConverterDispose, which I was
able to get a stack track for this crash:
SMCX StationMaster Mach-O(13247,0xa000ed98) malloc: *** error for
object 0x2140200: incorrect checksum for freed object - object was
probably modified after being freed, break at szone_error to debug
SMCX StationMaster Mach-O(13247,0xa000ed98) malloc: *** set a
breakpoint in szone_error to debug
Program received signal: "EXC_BAD_ACCESS".
mi_cmd_stack_list_frames: Not enough frames in stack.
#0 0x900073f8 in szone_free
#1 0x94157d34 in operator delete
#2 0x94161db0 in operator delete[]
#3 0x94161c2c in BufferedAudioConverter::~BufferedAudioConverter
#4 0x94161b94 in CBRConverter::~CBRConverter
#5 0x94161d6c in Reinterleaver::~Reinterleaver
#6 0x9416193c in AudioConverterChain::~AudioConverterChain
#7 0x9416188c in AudioConverterDispose
#8 0x00219580 in ASDAudioPlayer::Shutdown at ASDAudioPlayer.cpp:602
#9 0x00219948 in ASDAudioUnitPlayer::Shutdown at ASDAudioPlayer.cpp:
1015
#10 0x0021ada0 in ASDAudioUnitPlayer::~ASDAudioUnitPlayer at
ASDAudioPlayer.cpp:1009
#11 0x001ebca4 in Audio_PlayAbort at Audio_Utilities.cc:1458
#12 0x00215150 in WrapAudio_PlayAbort at SoundWrapper.cp:181
#13 0x00206bc8 in MakeRingTone at MyTelephony.c:531
#14 0x0020716c in PhoneCallPresented at MyTelephony.c:618
#15 0x000d30f0 in CheckHotPoints at MySerial.c:3501
#16 0x000d5550 in NormalCh at MySerial.c:3833
#17 0x000d698c in ProcessByte at MySerial.c:4195
#18 0x000d6c9c in ProcessBuffer at MySerial.c:4268
#19 0x000d71a4 in ProcessSerial at MySerial.c:4375
#20 0x000bb464 in MELProgress at MELHelp.c:983
#21 0x000b7834 in ProcessEvent at MEL.c:2136
#22 0x000b78b0 in DoEvent at MEL.c:2145
#23 0x001badb0 in MainLoop at SMCMain.c:93
#24 0x001bc630 in main at SMCMain.c:599
This just means some later deallocation triggered by
AudioConverterDispose() is running into the corrupted free list --
it's not this code which is at fault.
As the error message preceding the crash says, you can set a
breakpoint in gdb (or Xcode) on szone_error (or, even better,
malloc_printf) that may help you catch this in the act. Alternately,
you can run with GuardMalloc and that will definitely catch the
double-free if there is one. You can do "man libgmalloc" to find out
more about GuardMalloc or you can just do this in Terminal:
DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
MALLOC_ALTIVEC_SIZE=1 /path/to/MyApp.app/Contents/Macos/MyApp
You can also use GuardMalloc in an Xcode debug session by choosing
the Debug -> Enable Guard Malloc menu item before launching the debug
session.
hth,
stephen
_______________________________________________
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