Re: Crash in MP3AudioFile::GetContiguousPacketCountAndSize
Re: Crash in MP3AudioFile::GetContiguousPacketCountAndSize
- Subject: Re: Crash in MP3AudioFile::GetContiguousPacketCountAndSize
- From: Doug Wyatt <email@hidden>
- Date: Mon, 19 Sep 2005 18:21:04 -0400
On Sep 19, 2005, at 15:07, Jens Alfke wrote:
I've been using the PublicUtility classes some more. They allocated
more buffer memory than I liked, especially since
CAChannelMappingPlayer has a minor mistake in that its constructor
parameter is called "ioBufferSizeBytes" but is really in units of
*frames*, not bytes. This means the buffer scheme used by afplay
really allocates 768kbytes of buffers per player, not 96k as it
appears to!
Oops, good catch on the naming of that parameter.
Unfortunately when I lowered the buffer-size parameter in my
modified code from 0x8000 to 0x1000, I began to get occasional but
repeatable crashes on the CABufferQueue worker thread, i.e. while
reading from the input file (always an MP3 file in my case.)
Increasing the buffer size back to the original makes the problem
go away.
The crash is always in
MP3AudioFile::GetContiguousPacketCountAndSize (see full backtrace
below). This method has fallen off the end of a malloc block, into
unmapped memory. The block is *not* a buffer that I allocated,
neither the output buffer nor the ExtAudioFile's I/O buffer. I was
able to use malloc_history to find that the block was allocated by
MP3AudioFile itself, inside the call to ReadPackets. It's usually
of size 0x3000.
Any clues here? It may well be a bug I've introduced, but I've been
unable to figure out what causes it, since it manifests in code and
data that I don't control.
I tried to reproduce this by modifying afplay to pass 0x1000 to the
CAChannelMappingPlayer constructor, but everything still seems fine.
Can you please write a Radar and be sure to include a full backtrace
including registers? Also, does it only happen with some files? Any
file?
Thanks
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