Closed Bug 1316145 Opened 3 years ago Closed 3 years ago

Intermittent dom/media/tests/mochitest/test_peerConnection_capturedVideo.html | application crashed [@ mozilla::TaskQueue::Dispatch]

Categories

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

52 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
firefox50 --- unaffected
firefox51 --- unaffected
firefox52 --- fixed
firefox53 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: jwwang)

References

Details

(Keywords: intermittent-failure, regression)

Attachments

(1 file, 1 obsolete file)

Component: Audio/Video → WebRTC
I'm still reading the code. As far as I see it is rather easy to enter the state where the thread is closing yet we're still dispatching to it. For example Canonical::Set.
And all the StableState usage... if one happens to try to close the AbstractThread in a nested event loop, StableState stuff will just run using closing thread.

But haven't managed to reproduce locally, so don't know which case this is about.
Rank: 35
Priority: -- → P3
jww, jya, do you think you could have time to look at this a bit?

The current guess is that some thread somewhere is shutting down and after that we still try to dispatch tasks to it. (Possibly nested event loop spinning in the main thread is related here?)
As far as I see bug 1306591 shouldn't be able to cause this, but it could certainly reveal wrong assumptions in code.
Flags: needinfo?(jyavenard)
Flags: needinfo?(jwwang)
Bug 1225731 will help us figure out which callsite is doing Dispatch() after task queue shutdown. Let's just wait for reports to reveal it.
Flags: needinfo?(jwwang)
Depends on: 1318226
This is a regression caused by bug 1315581.
Assignee: nobody → jwwang
Blocks: 1315581
Flags: needinfo?(jyavenard)
Keywords: regression
Component: WebRTC → Audio/Video: Playback
Version: unspecified → 52 Branch
Attachment #8812077 - Flags: review?(jyavenard)
Attachment #8812077 - Attachment is obsolete: true
Attachment #8812077 - Flags: review?(jyavenard)
Attachment #8812115 - Flags: review?(jyavenard)
Comment on attachment 8812115 [details]
Bug 1316145 - pass DontAssertDispatchSuccess when dispatching events because it is hard to enforce notification happens before AbstractThread shutdown.

https://reviewboard.mozilla.org/r/93994/#review94142
Attachment #8812115 - Flags: review?(jyavenard) → review+
Pushed by jwwang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6e593b6f2ee6
pass DontAssertDispatchSuccess when dispatching events because it is hard to enforce notification happens before AbstractThread shutdown. r=jya
https://hg.mozilla.org/mozilla-central/rev/6e593b6f2ee6
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Please request Aurora on this when you get a chance.
Flags: needinfo?(jwwang)
Comment on attachment 8812115 [details]
Bug 1316145 - pass DontAssertDispatchSuccess when dispatching events because it is hard to enforce notification happens before AbstractThread shutdown.

Approval Request Comment
[Feature/regressing bug #]:1315581
[User impact if declined]:assertion
[Describe test coverage new/current, TreeHerder]:TreeHerder
[Risks and why]: Low. The change is quite simple.
[String/UUID change made/needed]:none
Flags: needinfo?(jwwang)
Attachment #8812115 - Flags: approval-mozilla-aurora?
Comment on attachment 8812115 [details]
Bug 1316145 - pass DontAssertDispatchSuccess when dispatching events because it is hard to enforce notification happens before AbstractThread shutdown.

one-line fix for intermittent regression, let's get this in aurora52
Attachment #8812115 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.