Closed Bug 723793 Opened 12 years ago Closed 11 years ago

Lazily initialize libcubeb

Categories

(Core :: Audio/Video, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla14

People

(Reporter: kinetik, Assigned: kinetik)

References

Details

Attachments

(1 file, 1 obsolete file)

Initializing libcubeb from nsAudioStream::InitLibrary means it is initialized even in situations where it'll never be used (e.g. inside xpcshell).  It also breaks the delayload optimization for the gkmedias DSO added in bug 712175.
Attachment #594045 - Flags: review?(roc)
Comment on attachment 594045 [details] [diff] [review]
Lazily initialize libcubeb on first use.

Review of attachment 594045 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/media/nsAudioStream.cpp
@@ +963,4 @@
>  
>    {
>      cubeb_stream* stream;
> +    if (cubeb_stream_init(GetCubebContext(), &stream, "nsBufferedAudioStream", params,

Hoist this out so we only have to take the lock once per Init.
Attachment #594045 - Flags: review?(roc) → review+
Attachment #594045 - Attachment is obsolete: true
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/62b24f89b354 for a couple of unhappy Windows crashtest runs:

https://tbpl.mozilla.org/php/getParsedLog.php?id=9054674&tree=Mozilla-Inbound
REFTEST TEST-START | file:///C:/talos-slave/test/build/reftest/tests/docshell/base/crashtests/369126-1.html | 402 / 2012 (19%)
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
###!!! ABORT: Main-thread-only object used off the main thread: file e:/builds/moz2_slave/m-in-w32/build/xpcom/base/nsCycleCollector.cpp, line 1307
###!!! ABORT: Main-thread-only object used off the main thread: file e:/builds/moz2_slave/m-in-w32/build/xpcom/base/nsCycleCollector.cpp, line 1307
TEST-UNEXPECTED-FAIL | file:///C:/talos-slave/test/build/reftest/tests/docshell/base/crashtests/369126-1.html | Exited with code 3 during test run

https://tbpl.mozilla.org/php/getParsedLog.php?id=9054770&tree=Mozilla-Inbound
REFTEST TEST-START | file:///c:/talos-slave/test/build/reftest/tests/docshell/base/crashtests/436900-2.html | 409 / 2012 (20%)
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/docshell/base/crashtests/436900-2.html | Exited with code 3 during test run
Hmm, now I'm deeply confused.

Those two failures were a pair of oranges, on the push two after this and the push three after this.

Once I backed this out for clearly being at fault there, then I looked at a pair of purple Windows crashtests, one push after this and one push before this, and they were

https://tbpl.mozilla.org/php/getParsedLog.php?id=9052396&tree=Mozilla-Inbound
REFTEST TEST-PASS | file:///c:/talos-slave/test/build/reftest/tests/docshell/base/crashtests/403574-1.xhtml | (LOAD ONLY)
REFTEST INFO | Loading a blank page
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/docshell/base/crashtests/403574-1.xhtml | application timed out after 330 seconds with no output

https://tbpl.mozilla.org/php/getParsedLog.php?id=9054106&tree=Mozilla-Inbound
REFTEST TEST-START | file:///c:/talos-slave/test/build/reftest/tests/docshell/base/crashtests/430628-1.html | 405 / 2012 (20%)
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
Assertion failed: r == MMSYSERR_NOERROR, file e:/builds/moz2_slave/m-in-w32/build/media/libcubeb/src/cubeb_winmm.c, line 398
TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/docshell/base/crashtests/430628-1.html | application timed out after 330 seconds with no output

So, um, the assertions were expected and nonfatal and already present, and this *did* cause crashes? Or, you just picked an astonishingly bad time to push it, when seemingly-related failures were planning on happening anyway? Or, your patch actually travelled backward in time, to affect the push before you pushed it?
This must be a problem with the original libcubeb push (bug 623444).  I'll disable that code with a pref change for now.
Assignee: nobody → kinetik
Relanded:

http://hg.mozilla.org/integration/mozilla-inbound/rev/b99da5d23b1b
Target Milestone: mozilla13 → mozilla14
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/b99da5d23b1b
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 793024
No longer depends on: 793024
Depends on: 944707
You need to log in before you can comment on or make changes to this bug.