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 10:43:28 -0700
On Jul 19, 2005, at 9:40, Evan Olcott wrote:
On Jul 19, 2005, at 11:09 AM, Doug Wyatt wrote:
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?
Because I'm using AudioConvertorConvertBuffer(), I don't think I
*have* a callback to trap, nor do I have an mDataByteSize to fill -
this is direct buffer-to-buffer with given byte size conversion:
AudioConverterConvertBuffer(fileConvertor, fileBufferDataByteSize,
fileBufferData, &bufferList->mBuffers[c].mDataByteSize, bufferList-
>mBuffers[c].mData);
fileBufferData is the data I've read from the audio file itself,
and bufferList is the set of buffers I send back from the callback
(the [c] is because I do this separately for each channel).
bufferList stays static throughout, so we know that's good. Since
we're getting a bad *load*, I'd point the finger that the
fileBufferDataByteSize or fileBufferData - but I've just been
filling that stuff up just previous to the ConvertBuffer() call.
Maybe something's spilling out?
Any other ideas? (Liked those, tho)...
OK, so I'd triple-check fileBufferDataByteSize and bufferList-
>mBuffers[c].mDataByteSize.
If fileBufferDataByteSize is too large, of course we'll read past the
end and crash.
If bufferList->mBuffers[c].mDataByteSize (on entry) translates into
more frames than fileBufferDataByteSize, we *should* be stopping, but
if not, then the converter would then keep trying to convert and crash.
The next thing I'd try is logging fileBufferDataByteSize and
fileBufferData before each call. Then when it crashes -- how does r3
relate? Is it inside the last fileBufferData, a little past the end,
or somewhere completely different?
It'd also be interesting to see the output of:
CAShow(fileConvertor);
-- is this a simple PCM-to-PCM converter with no rate conversion or
de/interleaving, or is it more complex?
Doug
--
Doug Wyatt
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