This may or may not be the same thing that is intermittent for 64-bit Linux, that I (probably mistakenly) included in bug 557432. For 64-bit OS X, see either opt or debug 10.6 M1/5 column in http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&noignore=1 since it fails every time and is thus one of the reasons M1 is still hidden there. http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277015781.1277020418.12954.gz Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central debug test mochitests-1/5 on 2010/06/19 23:36:21 s: talos-r3-snow-021 51281 INFO TEST-PASS | /tests/content/media/test/test_playback_errors.html | 448636.ogv only one error fired - 1 should equal 1 --DOMWINDOW == 14 (0x1200c2138) [serial = 1463] [outer = 0x10f842820] [url = http://mochi.test:8888/tests/content/media/test/test_playback.html] WARNING: 1 sort operation has occurred for the SQL statement '0x11f6bad78'. See https://developer.mozilla.org/En/Storage/Warnings details.: file /builds/slave/mozilla-central-macosx64-debug/build/storage/src/mozStoragePrivateHelpers.cpp, line 133 WARNING: An event was posted to a thread that will never run it (rejected): file /builds/slave/mozilla-central-macosx64-debug/build/xpcom/threads/nsThread.cpp, line 371 WARNING: leaking reference to nsTimerImpl: file /builds/slave/mozilla-central-macosx64-debug/build/xpcom/threads/nsTimerImpl.cpp, line 493 WARNING: 1 sort operation has occurred for the SQL statement '0x11f6bad78'. See https://developer.mozilla.org/En/Storage/Warnings details.: file /builds/slave/mozilla-central-macosx64-debug/build/storage/src/mozStoragePrivateHelpers.cpp, line 133 51282 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_playback_errors.html | Test timed out. 51283 INFO SimpleTest finished /tests/content/media/test/test_playback_errors.html in 325371ms Every one that I looked at was in the same place, after the "448636.ogv only one error fired" pass, so I assume it's a problem in the next test file.
Yeah, we're timing out while loading the metadata for bug504843.ogv. This file has enormous frame sizes (844832x1012384), and we're spending a lot of time in malloc/memset allocating memory for the frame (and eventually failing because we don't quite have 3.1TB of memory free). The bug is that we call th_decode_alloc before we perform the max frame size checks. Patch coming up.
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
The other bug is that we only do the frame size check on the picture region, which means this file passes that test as the picture region is only 320x240.
Created attachment 452616 [details] [diff] [review] patch v0 It's likely this is causing problems on all 64-bit builds.
Attachment #452616 - Flags: review?(roc)
Attachment #452616 - Flags: review?(roc) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.