Re: Crash deep inside CoreAudio
Re: Crash deep inside CoreAudio
- Subject: Re: Crash deep inside CoreAudio
- From: Doug Wyatt <email@hidden>
- Date: Tue, 19 Jul 2005 09:09:38 -0700
OK, it's crashing on a load. The source buffer pointer is r3, which
is 0x0000000006555820.
If it were happening on your machine, I'd add code to the end of the
AudioConverter input callback function to read bytes from the
beginning and from the end of the buffer being returned to the
AudioConverter. Then you'd presumably crash in your own code and be
able to debug more directly. If you didn't crash, that would say
something else ...
Since it's not happening on your machine, I'd suggest scrutinizing
the code in your input callback and see how it might be possible to
be returning a bad buffer pointer or size. Are you filling in
mDataByteSize in the AudioBuffer?
Doug
--
Doug Wyatt
Core Audio, Apple
On Jul 19, 2005, at 8:56, Evan Olcott wrote:
My destination buffers aren't moving (or shouldn't), but my source
buffers get created and filled before this call - so if that memory
block was bad, I'm guessing it would have showed up before poor
"Swap..." hit it.
Also note - this doesn't happen on my machine, but a user's...
Here's the further info:
Date/Time: 2005-07-19 15:07:26.225 +0100
OS Version: 10.4.2 (Build 8C46)
Report Version: 3
Version: 2.1 (2.1.2)
PID: 2784
Thread: 9
Thread 9 crashed with PPC Thread State 64:
srr0: 0x00000000940ceb9c srr1:
0x100000000200f030 vrsave: 0x00000000cffc0000
cr: 0x42022440 xer: 0x0000000000000000 lr:
0x000000009406035c ctr: 0x000000000000003f
r0: 0x0000000000040040 r1: 0x00000000f00fe040 r2:
0x0000000000000010 r3: 0x0000000006555820
r4: 0x00000000065db040 r5: 0x00000000000003f0 r6:
0x000000009406035c r7: 0x0000000006556000
r8: 0x00000000cffc0000 r9: 0x0000000000000030 r10:
0x0000000000040000 r11: 0x0000000000000020
r12: 0x0000000000000100 r13: 0x0000000000000000 r14:
0x0000000000000001 r15: 0x00000000aa0c1e10
r16: 0x0000000000000001 r17: 0x00000000f00fe9e0 r18:
0x00000000a4056278 r19: 0x0000000005e8f010
r20: 0x00000000f00fe868 r21: 0x0000000005e8bda0 r22:
0x0000000000000000 r23: 0x00000000f00fe0e0
r24: 0x00000000f00fe0e4 r25: 0x0000000000001000 r26:
0x00000000005f51f0 r27: 0x0000000000001000
r28: 0x0000000005e7e6a8 r29: 0x0000000005e475e8 r30:
0x0000000000000000 r31: 0x00000000940802f8
0x945ce000 - 0x94830fff com.apple.QuickTime 7.0.1 /System/
Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
On Jul 19, 2005, at 10:43 AM, Doug Wyatt wrote:
It's either a bad source or destination buffer pointer.
You could disassemble the function and see which (is the crashing
instruction a load or a store?). So could I if I knew what version
of the OS/QuickTime you're using.
It'd also be useful to look at the PPC registers -- is the bad
pointer NULL or some other bad address?
Doug
On Jul 19, 2005, at 7:31, Evan Olcott wrote:
OK - under what circumstances would I get a crash in CoreAudio
like this?
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x06555820
Thread 9 Crashed:
0 ....audio.toolbox.AudioToolbox 0x940ceb9c
SwapInt16ToFloat32_Altivec + 580
1 ....audio.toolbox.AudioToolbox 0x9405f130
CBRConverter::RenderOutput(CABufferList*, unsigned long, unsigned
long&, AudioStreamPacketDescription*) + 204
2 ....audio.toolbox.AudioToolbox 0x9405ee5c
BufferedAudioConverter::FillBuffer(unsigned long&,
AudioBufferList&, AudioStreamPacketDescription*) + 292
3 ....audio.toolbox.AudioToolbox 0x9405efd8
AudioConverterChain::RenderOutput(CABufferList*, unsigned long,
unsigned long&, AudioStreamPacketDescription*) + 136
4 ....audio.toolbox.AudioToolbox 0x940c6c68
AudioConverterChain::ConvertBuffer(unsigned long, unsigned char*,
unsigned long&, unsigned char*) + 180
5 ....audio.toolbox.AudioToolbox 0x94080398
AudioConverterConvertBuffer + 168
6 com.audioƒile.SampleManager 0x00021978 -
[AFAudioFileWrapper(ReadWrite)
loadBufferFromPCMSource:toBufferList:reverse:] + 2740
(AFAudioFileWrapper_ReadWrite.m:252)
This is after a rather long (85 item) stack of Audio Units and
what not - and this happens *rarely* and *intermittently* (mostly
it works without a hitch) but it's mostly right there at
"SwapInt16ToFloat32_Altivec". What the heck is it getting from me
that's causing it to black out right there?
Take note that this is not the main thread, nor is it the
CoreAudio thread - but a "processing" thread where I have built a
separate AUGraph for this task. Could there be some thread
conflict going on here?
Anyone seen this before or have an idea of what poor
"SwapInt16ToFloat32_Altivec" might be choking on?
_______________________________________________
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