Crash in ExtAudioFileDispose
| Originator: | ddribin | ||
| Number: | rdar://7226263 | Date Originated: | 15-Sep-2009 05:52 PM |
| Status: | Duplicate/7100093 | Resolved: | |
| Product: | Mac OS X | Product Version: | 10.6.1/10B504 |
| Classification: | Crash/Hang/Data Loss | Reproducible: | Unable |
15-Sep-2009 05:52 PM Dave Dribin: Summary: We are getting reports from customers with crashes in ExtAudioFileDispose. Here's the backtrace for the crashed thread: Thread 5 Crashed: 0 libSystem.B.dylib 0x9096dbfd __abort + 136 1 libSystem.B.dylib 0x90950934 release_file_streams_for_task + 0 2 ....audio.toolbox.AudioToolbox 0x970af497 UInt32ToHexString(char*, unsigned long, unsigned long) + 183 3 ....audio.toolbox.AudioToolbox 0x970af556 MP4AudioFile::FillGaplessString(char*) + 110 4 ....audio.toolbox.AudioToolbox 0x970b23ed MP4AudioFile::Close() + 627 5 ....audio.toolbox.AudioToolbox 0x9700fa25 AudioFileClose + 77 6 ....audio.toolbox.AudioToolbox 0x97072ef6 ExtAudioFile::Close() + 206 7 ....audio.toolbox.AudioToolbox 0x9707303e ExtAudioFile::~ExtAudioFile() + 40 8 ....audio.toolbox.AudioToolbox 0x9706889c XExtAudioFile::~XExtAudioFile() + 92 9 ....audio.toolbox.AudioToolbox 0x97068554 ExtAudioFileDispose + 37 10 com.bitmaki.textcast 0x000350bb 0x1000 + 213179 11 com.bitmaki.textcast 0x0003413f 0x1000 + 209215 12 com.bitmaki.textcast 0x0003409e 0x1000 + 209054 13 com.apple.Foundation 0x920b7964 -[NSThread main] + 45 14 com.apple.Foundation 0x920b7914 __NSThread__main__ + 1499 15 libSystem.B.dylib 0x90890fe1 _pthread_start + 345 16 libSystem.B.dylib 0x90890e66 thread_start + 34 Steps to Reproduce: I've not yet been able to reproduce, but we've gotten numerous crashes with this backtrace, all on Snow Leopard. Expected Results: N/A Actual Results: N/A Regression: Seems new to Snow Leopard (10.6 and 10.6.1). We have not seen this backtrace on 10.5.x. Notes: Attaching a sample crash log. 16-Sep-2009 10:49 PM Dave Dribin: I've now got a reproducible case. It happens converting a large AIFF to M4A. Here's a 688M AIFF file: <http://www.dribin.org/dave/tmp/text2speech.aiff> Download it and convert it like this, and it'll crash: % ls -l text2speech.aiff -rw-r--r-- 1 dave staff 721908666 Sep 16 20:04 text2speech.aiff % afconvert -f 'm4af' -d 'aac ' text2speech.aiff text2speech.m4a zsh: abort afconvert -f 'm4af' -d 'aac ' text2speech.aiff text2speech.m4a % ls -l text2speech.* -rw-r--r-- 1 dave staff 721908666 Sep 16 20:04 text2speech.aiff -rw-r--r-- 1 dave staff 67389884 Sep 16 20:08 text2speech.m4a I'm attaching a crash log, too (afconvert_2009-09-16-200825_fuji-sl.crash).
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
See #730346 for more information
I filed a duplicate with a lot more information and a way to reproduce the crash. See rdar://7230346 (Open Radar).
In short:
MP4AudioFile::FillGaplessString()andUInt32ToHexString()are both new in Snow Leopard's AudioToolbox framework. The crash is due to a buffer overflow encountered when writing really large MP4 files (try recording for 2 hours before closing the file). Since Snow Leopard's AudioToolbox is compiled using -fstack-protector or -fstack-protector-all, rather than silently corrupting the stack, it overwrites a byte of__stack_chk_guard. This results in a call to__stack_chk_fail, which tail-calls__abort. Since it tail-calls in its last instruction,__abort's return address isn't to__stack_chk_fail, but to the first instruction of the function following it,release_file_streams_for_task. That name in the crash report is just a red herring.See also http://openradar.appspot.com/6376115
See also: http://openradar.appspot.com/6376115 ExtAudioFileRead fails on big files
The bug is still present in 10.6.2
Date/Time: 2009-11-12 11:47:05.285 +0200 OS Version: Mac OS X 10.6.2 (10C540) Report Version: 6
Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information: __abort() called
Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x91ed2732 kill + 10 1 libSystem.B.dylib 0x91ed2724 kill$UNIX2003 + 32 2 libSystem.B.dylib 0x91f6598d raise + 26 3 libSystem.B.dylib 0x91f7b9d9 abort + 124 4 libSystem.B.dylib 0x91f5e71c release_file_streams_for_task + 0 5 ....audio.toolbox.AudioToolbox 0x9314ae2f UInt32ToHexString(char, unsigned long, unsigned long) + 183 6 ....audio.toolbox.AudioToolbox 0x9314aeee MP4AudioFile::FillGaplessString(char) + 110 7 ....audio.toolbox.AudioToolbox 0x9314dd85 MP4AudioFile::Close() + 627 8 ....audio.toolbox.AudioToolbox 0x930a9085 AudioFileClose + 77 9 ....audio.toolbox.AudioToolbox 0x9310c380 ExtAudioFile::Close() + 206 10 ....audio.toolbox.AudioToolbox 0x9310c4c8 ExtAudioFile::~ExtAudioFile() + 40 11 ....audio.toolbox.AudioToolbox 0x93101d20 XExtAudioFile::~XExtAudioFile() + 92 12 ....audio.toolbox.AudioToolbox 0x931019d8 ExtAudioFileDispose + 37 13 afconvert 0x0000946f 0x1000 + 33903
Yup, still in 10.6.2
If you're still seeing this on 10.6.2, please file a dupe.
Possible workaround
One workaround seems to be to use kAudioFileMPEG4Type instead of kAudioFileM4AType. Theoretically, a .mp4 should be the same as a .m4a, but it looks like this isn't the case here.
http://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A_file_extensions
If the .m4a vs. .mp4 doesn't matter, you may want to try this out.
Thanks ddribin I'll try it!
I can not thank you enough!