Closed Bug 1083664 Opened 11 years ago Closed 6 years ago

Intermittent test_dataChannel_basicAudio.html | undefined assertion name - Result logged after SimpleTest.finish() | Assertion failed: (ctx->active_streams == 0), function audiounit_destroy, file /builds/slave/m-in-osx64-d-000000000000000

Categories

(Core :: Audio/Video: cubeb, defect, P3)

Product:
Core
Component:
Audio/Video: cubeb
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: cbook, Unassigned)

References

(
URL
)

Details

(Keywords: assertion, intermittent-failure, Whiteboard: [leave open])

Rev4 MacOSX Snow Leopard 10.6 mozilla-inbound debug test mochitest-3 https://treeherder.mozilla.org/ui/logviewer.html#?job_id=3040148&repo=mozilla-inbound 20:34:40 INFO - 32 INFO TEST-UNEXPECTED-FAIL | /tests/dom/media/tests/mochitest/test_dataChannel_basicAudio.html | undefined assertion name - Result logged after SimpleTest.finish() 20:34:39 INFO - Assertion failed: (ctx->active_streams == 0), function audiounit_destroy, file /builds/slave/m-in-osx64-d-00000000000000000/build/media/libcubeb/src/cubeb_audiounit.c, line 450.
This assertion was added in bug 847903. What does it mean? This intermittent may have been exposed by bug 1035454, which caused us to run more of XPCOM shutdown in content processes. Previously, we'd exit(0) when we sent the xpcom-shutdown message to observers.
Blocks: 1035454
kinetik, do you have some idea of a fix here? In the short term, I can probably work around this by adding an OSX-only exit(0) to XPCOM shutdown, which is how I've worked around shutdown failures on Windows and B2G...
Flags: needinfo?(kinetik)
(In reply to Andrew McCreight [:mccr8] from comment #5) > This assertion was added in bug 847903. What does it mean? It is ensuring that all of the streams owned by a particular audio context were destroyed before the context was destroyed. If the assert fires, that means one or more streams were still alive when cubeb_destroy was called. (In reply to Andrew McCreight [:mccr8] from comment #9) > kinetik, do you have some idea of a fix here? In the short term, I can > probably work around this by adding an OSX-only exit(0) to XPCOM shutdown, > which is how I've worked around shutdown failures on Windows and B2G... It's probably a shutdown ordering issue in the WebRTC/MSG code, so jesup or padenot might be the best people to ask.
Flags: needinfo?(kinetik)
Randell, do you have some idea what might be going on here? Thanks.
Flags: needinfo?(rjesup)
This is officially the #1 failure on OrangeFactor. I'll be disabling the test shortly if we can't find a path forward here.
Assignee: nobody → padenot
I disabled test_dataChannel_basicAudio.html on OSX debug. We'll see if it helps vs. just moving the crashes to the next test instead (can't help but notice that it's the first test in the manifest). https://hg.mozilla.org/integration/mozilla-inbound/rev/49aa83aec979
Whiteboard: [test disabled on OSX debug][leave open]
(In reply to TBPL Robot from comment #411) *sigh* Disabling the entire directory on OSX debug until someone gets a handle on this. https://hg.mozilla.org/integration/mozilla-inbound/rev/20c60d4d8faa
Whiteboard: [test disabled on OSX debug][leave open] → [leave open]
Flags: needinfo?(rjesup)
Assignee: padenot → nobody
Component: Audio/Video → WebRTC
Component: WebRTC → Audio/Video: cubeb
Rank: 21
Flags: needinfo?(rjesup)
Priority: -- → P2
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3

Looks like this is stale, no intermittents for quite some time. Bug 1606690 also obsoletes this by replacing the cubeb_audiounit backend with a Rust rewrite.

URL: https://treeherder.mozilla.org/ui/lo... → https://treeherder.mozilla.org/ui/log...
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(rjesup)
You need to log in before you can comment on or make changes to this bug.