Closed Bug 1515068 Opened 2 years ago Closed 2 years ago

Assertion failure: mSrcStreamPausedGraphTime == GRAPH_TIME_MAX, at /builds/worker/workspace/build/src/dom/html/HTMLMediaElement.cpp:4665


(Core :: WebRTC: Audio/Video, defect, P2)




Tracking Status
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 --- wontfix
firefox66 --- fixed


(Reporter: jkratzer, Assigned: pehrsons)


(Blocks 1 open bug)


(Keywords: assertion, testcase)


(3 files)

Attached file testcase.html
Testcase found while fuzzing mozilla-central rev 7ce7e9407a75.

Assertion failure: mSrcStreamPausedGraphTime == GRAPH_TIME_MAX, at /builds/worker/workspace/build/src/dom/html/HTMLMediaElement.cpp:4665

rax = 0x0000565088352e40   rdx = 0x0000000000000000
rcx = 0x00007f584ae44baa   rbx = 0x00007f583defa000
rsi = 0x00007f5857b308b0   rdi = 0x00007f5857b2f680
rbp = 0x00007ffcacfe5650   rsp = 0x00007ffcacfe5640
r8 = 0x00007f5857b308b0    r9 = 0x00007f5858c8d740
r10 = 0x0000000000000000   r11 = 0x0000000000000000
r12 = 0x00007f583cd35b68   r13 = 0x00007f583e3a07f8
r14 = 0x0000000000000004   r15 = 0x00007ffcacfe5808
rip = 0x00007f5846ef7635
OS|Linux|0.0.0 Linux 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC 2018 x86_64
CPU|amd64|family 6 model 78 stepping 3|1
0|1||mozilla::WatchManager<mozilla::dom::HTMLMediaElement>::PerCallbackWatcher::Notify()::{lambda()#1}::operator()() const|||0x78
0|5||mozilla::detail::RunnableMethodImpl<mozilla::EventTargetWrapper*, void (mozilla::EventTargetWrapper::*)(), true, (mozilla::RunnableKind)0>::Run()||1106|0x13
0|7||mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int)||397|0x8
0|8||XPCJSContext::AfterProcessTask(unsigned int)||1252|0xb
0|9||nsThread::ProcessNextEvent(bool, bool*)||1215|0xc
0|10||NS_ProcessNextEvent(nsIThread*, bool)||468|0x11
0|19||XRE_InitChildProcess(int, char**, XREChildData const*)||753|0xc
0|20|firefox-bin|content_process_main(mozilla::Bootstrap*, int, char**)||49|0x14
Flags: in-testsuite?
The assertion is added in bug 1423241, :pehrsons, do you have any idea what's happened here? Thanks.
Flags: needinfo?(apehrson)
Assignee: nobody → apehrson
Blocks: 1423241
Component: DOM → WebRTC: Audio/Video
Flags: needinfo?(apehrson)
Just loading this testcase doesn't reproduce it for me. I tried flipping some autoplay prefs to make it allowed to play and all, but no luck. What are the instructions for running this?
Flags: needinfo?(jkratzer)
Attached file prefs-default-e10s.js
Andreas, could you try again using the attached prefs?  You can use ffpuppet ( to automatically create a new profile using those prefs.

python -m ffpuppet -p prefs-default-e10s.js ~/firefox/firefox -u testcase.html
Flags: needinfo?(jkratzer)
Rank: 15
Priority: -- → P2
This is failing consistently for me today when I join a call on (in an opt+debug build, both Linux and OS X).
STR, just in case:
* start a meeting while logged into a Google account
* from a second computer join the meeting while not logged into a Google account, request permission to join the meeting
* from the first computer, approve the new participant
* the assertion then fires on the second computer
(In reply to Jason Kratzer [:jkratzer] from comment #3)
> Created attachment 9032947 [details]
> prefs-default-e10s.js
> Andreas, could you try again using the attached prefs?  You can use ffpuppet
> ( to automatically create a new
> profile using those prefs.
> python -m ffpuppet -p prefs-default-e10s.js ~/firefox/firefox -u
> testcase.html

Thanks, this worked, even under rr.
So this happens because the watch manager dispatches the updated values and makes the whole thing async. So after the time is updated we might still get paused before UpdateSrcStreamTime() runs.

I'll probably have to drop the asserts. It's not such a big deal, but it'd be nice to be certain that no updates are dispatched while we're paused, as it's nothing but wasted cycles.
This is harmless in non-debug and we should honestly have spotted it sooner. I'm not gonna bother with a crashtest.
This can legitimately happen while paused since the watchmanager calling this
is dispatching the calls. As such they're out of sync with the paused state,
and we need to allow updating the time while paused.

FireTimeUpdate does ignore the call if the time hasn't actually been updated,
so the only impact from this is that we could do a lot of unnecessary
dispatching while paused without noticing.
Pushed by
Allow UpdateSrcStreamTime while paused. r=jya

Comment on attachment 9034430 [details]
Bug 1515068 - Allow UpdateSrcStreamTime while paused. r?jya

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1423241

User impact if declined: Debug build assertion failures

Is this code covered by automated tests?: No

Has the fix been verified in Nightly?: No

Needs manual test from QE?: No

If yes, steps to reproduce:

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): Removes a few assertions that can legitimately happen. There's a change to logic too, but it's trivial and simply ignores redundant currentTime updates.

String changes made/needed:

Attachment #9034430 - Flags: approval-mozilla-beta?
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

Comment on attachment 9034430 [details]
Bug 1515068 - Allow UpdateSrcStreamTime while paused. r?jya

Given that there's no real user impact here outside of debug builds, I think this can just ride the trains.

Attachment #9034430 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
You need to log in before you can comment on or make changes to this bug.