Closed Bug 1330212 Opened 3 years ago Closed 3 years ago
_get User Media _media Stream Track Clone .html | application crashed [@ mozilla::Cycle Collected JSContext::Process Metastable State Queue]
Filed by: philringnalda [at] gmail.com https://treeherder.mozilla.org/logviewer.html#?job_id=67852903&repo=mozilla-inbound https://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-inbound-android-api-15/1484103726/mozilla-inbound_ubuntu64_vm_armv7_large_test-mochitest-media-2-bm51-tests1-linux64-build106.txt.gz
Component: Audio/Video → Audio/Video: MediaStreamGraph
Priority: -- → P1
Andreas, it says "clone" in the title, any idea of why it happens or a possible dupe ? :-)
I think the "clone" in the title is a huge coincidence, but I know that the assert here is the same as in bug 1317501. But it looks like it's from a new callsite. MSG runnables run on main thread in stable state and at that point there are certain things they're not allowed to do. To my untrained eye just looking at the stack, it looks like we're not allowed to destroy the SystemClockDriver directly in the MSG runnable because that will process its thread's queue, and there's some event that is not allowed to run in stable state. smaug knows more here maybe?
Flags: needinfo?(pehrson) → needinfo?(bugs)
Yeah, totally not acceptable to spin eventloop at that point (nsIThread::Shutdown may spin eventloop). Call shutdown() using a runnable?
How about this?
Assignee: nobody → rjesup
Status: NEW → ASSIGNED
Comment on attachment 8826057 [details] [diff] [review] Release GraphDrivers outside of StableState runnable to avoid spinning the event queue Is it guaranteed same issue can't happen in other use of SystemClockDriver?
Attachment #8826057 - Flags: review?(bugs) → review+
(In reply to Olli Pettay [:smaug] from comment #6) > Comment on attachment 8826057 [details] [diff] [review] > Release GraphDrivers outside of StableState runnable to avoid spinning the > event queue > > Is it guaranteed same issue can't happen in other use of SystemClockDriver? the issue only arises when we're switching drivers in RunInStableState; other switches happen in various Media threads or in non-StableState MainThread runnables. Smaug: is there any way we can add assertions or warnings to event-loop-spinning in states we don't want it in, even if only for Debug builds, or even if it requires whitelisting a number of known-ok uses? This is a usually subtle landmine that's tripped many an engineer over the years - and as with this case, the event-loop-spinning is often not obvious to the person who caused it (for example, it may depend on who's holding the last ref to an object such as a thread, like this one).
See previous comment
So we would need to add some annotations on stack when spinning event loop isn't ok and then assert in thread code if someone is trying to spin the loop. That might be useful. naAutoScriptBlocker could inherit from such "annotation class", so that we'd cover most common cases easily, and then add some more annotations for metastable and stable states. I guess we could start from main thread only. This might not cover all the cases, for that some rather heavy static analysis would be needed, but possibly would be useful anyhow. Please file a bug and I'll try to find time to look at it if no one else will. This might be useful for Quantum DOM too.
Attachment #8826057 - Flags: review?(padenot) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/c90ec782d481 Release GraphDrivers outside of StableState runnable to avoid spinning the event queue r=smaug,padenot
Sounds like this affects 51/52 as well? Please nominate it for uplift.
This was caused by bug 1228226, which has been backed out of 53 already (and likely will soon be backed out of 52). The fix in this bug is still good to have in the tree; it's a good safety backstop against someone causing this problem again (until we have better checking via bug 1331036). If we don't back the other out of 52, and this is still needed there, we can uplift it to 52.
You need to log in before you can comment on or make changes to this bug.