Lazily initialize libcubeb

RESOLVED FIXED in mozilla14

Status

()

Core
Audio/Video
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: kinetik, Assigned: kinetik)

Tracking

Trunk
mozilla14
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

5 years ago
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.
(Assignee)

Comment 1

5 years ago
Created attachment 594045 [details] [diff] [review]
Lazily initialize libcubeb on first use.
(Assignee)

Updated

5 years ago
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+
(Assignee)

Comment 3

5 years ago
Created attachment 594047 [details] [diff] [review]
Lazily initialize libcubeb on first use.
(Assignee)

Updated

5 years ago
Attachment #594045 - Attachment is obsolete: true
(Assignee)

Comment 4

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/60fc46d5b1ca
Target Milestone: --- → mozilla13
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?
(Assignee)

Comment 7

5 years ago
This must be a problem with the original libcubeb push (bug 623444).  I'll disable that code with a pref change for now.

Updated

5 years ago
Assignee: nobody → kinetik
(Assignee)

Comment 8

5 years ago
Relanded:

http://hg.mozilla.org/integration/mozilla-inbound/rev/b99da5d23b1b
Target Milestone: mozilla13 → mozilla14
(Assignee)

Updated

5 years ago
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/b99da5d23b1b
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Depends on: 793024
(Assignee)

Updated

5 years ago
No longer depends on: 793024
(Assignee)

Updated

3 years ago
Depends on: 944707
You need to log in before you can comment on or make changes to this bug.