Created attachment 8905305 [details] trigger.html Testcase found while fuzzing mozilla-central rev 20170905-3ecda4678c49.
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
INFO: Last good revision: dec7cb09336ee273f362ce0550a36ef70d5202d3 INFO: First bad revision: a7e5cdf5c07f2e0b61fb7f5d62a7f080a7df19fb INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dec7cb09336ee273f362ce0550a36ef70d5202d3&tochange=a7e5cdf5c07f2e0b61fb7f5d62a7f080a7df19fb
Has Regression Range: --- → yes
status-firefox55: --- → unaffected
status-firefox56: --- → wontfix
status-firefox57: --- → affected
status-firefox58: --- → affected
status-firefox-esr52: --- → unaffected
I cannot reproduce this issue. I've tried loading the file from disk, and from a local server. Also, I'm doubtful the accused bug 1379091 is involved: That bug is slightly modifying the possible size of MediaCache's in-memory storage. But the trigger.html code should not even use MediaCache at all! I ran the test page with MOZ_LOG=MediaCache:5, and nothing came out from this component. The assertion happens in code called from MediaDevices.enumerateDevices(), which is part of WebRTC. MediaCache is on the playback side, which AFAICT is not happening in trigger.html. Ryan: How did you get there? Is it reliable?
Jan-Ivar, you probably have more knowledge about MediaManager&MediaDevices, would you see a link between the assertion in MediaManager and a change in MediaCache? (Or know someone who would know?) Thank you.
Hrm, not as sure as I thought I was. I'm getting different results now vs. what I was getting earlier. Turns out it runs a lot more reliably when opened from disk vs. running it from Bugzilla. INFO: Last good revision: e3bceb6eb287275e123cb92c487696c6c7325096 INFO: First bad revision: 1fb2d6e0aa2d82c2db246ecd75f7225fecc449ed INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e3bceb6eb287275e123cb92c487696c6c7325096&tochange=1fb2d6e0aa2d82c2db246ecd75f7225fecc449ed --> Bug 1320994 I was able to let the testcase run on rev e3bceb6eb287275e123cb92c487696c6c7325096 for a few minutes without crashing (when affected builds would typically crash within 10-15sec otherwise). And that culprit definitely looks a lot more plausible. Sorry for the confusion before. On a side note, this testcase is pure spawn of Satan evil.
Thanks Ryan, this is definitely bug 1320994. Looking at the code, OnNavigation() removes all the window's source listeners, while enumerateDevicesImpl when finished will remove one particular source listener. It's when the latter fails (because the former has already happened) that we fail the assert. Basically, when we navigate while enumerateDevices() is mid-flight. I think the proper thing to do would be to have OnNavigation() *not* clean up inactive source listeners, and after it has happened it should prevent promoting those inactive ones to active. jib, thoughts? Perhaps we can do something more radical, like cancel all pending enumerateDevices?
Assignee: nobody → jib
You need to log in before you can comment on or make changes to this bug.