Closed Bug 499512 Opened 11 years ago Closed 10 years ago
Crash in OGG : res2
_inverse at vorbis _res0 .c:849
Program received signal: “EXC_ARITHMETIC”, looks like a div by zero. #0 0x1358cb59 in res2_inverse at vorbis_res0.c:849 #1 0x1358e972 in mapping0_inverse at vorbis_mapping0.c:783 #2 0x13582af6 in vorbis_synthesis at vorbis_synthesis.c:81 #3 0x1354fddc in fs_vorbis_decode at fishsound_vorbis.c:158 #4 0x1354f122 in fish_sound_decode at fishsound_decode.c:117 #5 0x13554aff in oggplay_callback_audio at oggplay_callback.c:391 #6 0x1356204e in oggz_read_sync at oggz_read.c:483 #7 0x135623af in oggz_read at oggz_read.c:587 #8 0x13553b95 in oggplay_step_decoding at oggplay.c:691 #9 0x13540fec in nsOggDecodeStateMachine::DecodeFrame at nsOggDecoder.cpp:732 #10 0x13546683 in nsOggDecodeStateMachine::Run at nsOggDecoder.cpp:1428 #11 0x005759e4 in nsThread::ProcessNextEvent at nsThread.cpp:510 #12 0x004fe968 in NS_ProcessNextEvent_P at nsThreadUtils.cpp:227 #13 0x00575bf3 in nsThread::ThreadFunc at nsThread.cpp:254 #14 0x00728465 in _pt_root at ptthread.c:228 #15 0x96291155 in _pthread_start #16 0x96291012 in thread_start
I've just grabbed Monty and he had a hunch what could cause this problem. Currently debugging it, and he might already have a patch for this in trunk of vorbis... gonna get back ASAP as i find out if this is really the case.
debugged it with Monty and he says that this bug has been fixed in vorbis' RC version, which is just about to become a release. Although, according to Chris it still crashes with oggplayer using the latest libvorbis from trunk. Most probably the error code from vorbis is not handled in fishsound.... tracking it down.
The file crashes using vorbisfile_example from latest libvorbis svn for me.
"yes because vorbisfile_example is not checking the return code" by Monty ;)
Check some return values, and if error occurred propagate it... This patch fixes the bug, but only if the RC version of libvorbis is used.
Is this always a safe divide-by-zero, or does the missing error checks mean it's decoding uninitialized who knows what and might be exploitable if different values were present?
This crashes for me on 3.5.1, but not on trunk (mozilla-central revision 9dfacae57238) Fixed?
Fixed on m-c by bug 512328.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
bug 512328 was backed out due to bug 513999 :(
I'm not sure which oggplay changeset from bug 512328 stopped this bug from occurring. We should investigate the libfishsound fix wiking posted above.
blocking1.9.1: --- → ?
Is this being kept open to pick up Viktor's fix, or do we need a followup bug? fishsound definitely needs that patch, leaving Vorbis API calls unchecked is dangerous.
Testcase no longer crashes. I don't think this was fixed by bug 512328 checkin, as we still didn't crash in the firefox-3.7a 2009-09-20-05 nightly, which was before the 512328 checkin. We do play the file now thanks to bug 512328 though. May as well take Viktor's patch in a separate bug; it no longer helps to solve the bug as filed.
(In reply to comment #14) > May as well take Viktor's patch in a separate bug; it no longer helps to solve > the bug as filed. Bug 519097.
Flags: blocking1.9.2? → blocking1.9.2-
bug 512328 is being landed on the 1.9.1 branch -- we'll see if that fixes it on that branch.
blocking1.9.1: ? → .4+
This was fixed by the landing of bug 501279, so it's now fixed on trunk, 1.9.2, and 1.9.1. Note that the liboggplay update in bug 512328 additionally makes the testcase file playable - that's on all 3 major branches as well.
Verified for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124pre) Gecko/20090930 Shiretoko/3.5.4pre. Testcase crashes 126.96.36.199 cleanly.
Is it known which vorbis fix (if any) was needed to address this?
You need to log in before you can comment on or make changes to this bug.