Open Bug 1137632 Opened 5 years ago Updated 2 years ago

Assertion failure after tab/browser sharing and using replaceTrack ( outputTrack->GetEnd() == GraphTimeToStreamTime(interval.mStart) )


(Core :: WebRTC, defect, P4)

33 Branch



Blocking Flags:


(Reporter: standard8, Unassigned)



(Keywords: crash)


(1 file)


1) Use in-development Firefox Hello tab sharing and the patches on bug 1136871.
2) Set up Hello call in-room
3) Share Tabs
4) Stop sharing tabs (without switching)
5) Leave conversation
6) Close conversation window

=> No crash/assertion

7) Re-enter the room
8) Share Tabs
9) Switch the tab that is shown in the window
10) Stop sharing tabs
11) Leave conversation
12) Close conversation window

=> Crashes with a debug assertion - see the stack below:

Assertion failure: outputTrack->GetEnd() == GraphTimeToStreamTime(interval.mStart) (Samples missing), at /Users/mark/loop/gecko-dev/dom/media/TrackUnionStream.cpp:279
#01: mozilla::MediaStreamGraphImpl::ProduceDataForStreamsBlockByBlock(unsigned int, int, long long, long long)[/Users/mark/loop/gecko-dev/objdir-ff/dist/ +0x1f3ef40]
#02: mozilla::MediaStreamGraphImpl::Process(long long, long long)[/Users/mark/loop/gecko-dev/objdir-ff/dist/ +0x1f3f491]
#03: mozilla::MediaStreamGraphImpl::OneIteration(long long, long long, long long, long long)[/Users/mark/loop/gecko-dev/objdir-ff/dist/ +0x1f3fba4]
#04: mozilla::AudioCallbackDriver::DataCallback(float*, long)[/Users/mark/loop/gecko-dev/objdir-ff/dist/ +0x1ef727a]
#05: audiounit_output_callback[/Users/mark/loop/gecko-dev/objdir-ff/dist/ +0x32664b3]
#06: AUConverterBase::RenderBus(unsigned int&, AudioTimeStamp const&, unsigned int, unsigned int)[/System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio +0x8230]
#07: AUBase::DoRenderBus(unsigned int&, AudioTimeStamp const&, unsigned int, AUOutputElement*, unsigned int, AudioBufferList&)[/System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio +0x5c61]
#08: AUBase::DoRender(unsigned int&, AudioTimeStamp const&, unsigned int, unsigned int, AudioBufferList&)[/System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio +0x4515]
#09: AUHAL::AUIOProc(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*)[/System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio +0xb878]
#10: HALC_ProxyIOContext::IOWorkLoop()[/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio +0x279db]
#11: HALC_ProxyIOContext::IOThreadEntry(void*)[/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio +0x26add]
#12: HALB_IOThread::Entry(void*)[/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio +0x2699d]
#13: _pthread_body[/usr/lib/system/libsystem_pthread.dylib +0x1899]
#14: _pthread_struct_init[/usr/lib/system/libsystem_pthread.dylib +0x172a]
This is audio. Are we replaceTracking audio? Byron, do your patches to remove unused streams consider audio tracks?
Flags: needinfo?(standard8)
Flags: needinfo?(docfaraday)
The sdk has an option to replace audio, but I've just confirmed that it isn't actually being activated. I also tried commenting it out to doubly make sure.
Flags: needinfo?(standard8)
The code that prunes unused streams does not care what kind of track was the last to go.
Flags: needinfo?(docfaraday)
Blocks: 1115336
We've just had an update of the sdk, that seems to be tidying things up better with respect to the previous tracks, and managing the new ones.

Do we still want to try and find out what's going on here, or close as WFM?
Flags: needinfo?(jib)
Closed: 5 years ago
Flags: needinfo?(jib)
Resolution: --- → WORKSFORME
I don't think this can be closed yet. If we have an assert, that means
that there is presumably a bug in the C++ code. Just because the
SDK no longer exercises it doesn't mean that it can't be exercised from
content JS.
Resolution: WORKSFORME → ---
Paul can you take a look? I hear Mark is willing to make a build with the old sdk so that we can figure out what's going on here.
Flags: needinfo?(padenot)
If someone can hand me a (preferably debug/non-opt if it can be reproed there) build, I'm happy to have a look. Any platform will do, just do what is easier.
Flags: needinfo?(padenot)
Attached file debug trace
This is video, not audio. It's not clear to me if it is the remote camera, local camera, or the screen sharing, because it seems like listeners have been removed already, so I can't go to the *Engine.

In any case, according to the gdb trace attached, video frames are missing from the stream, maybe that's the screen capture that forgot to add a final frame or something?
Odd, in comment 0 it's in the audio driver:
>#04: mozilla::AudioCallbackDriver::DataCallback(float*, long)[/Users/mark/loop/gecko-dev/objdir-ff/dist/ +0x1ef727a]
>#05: audiounit_output_callback[/Users/mark/loop/gecko-dev/objdir-ff/dist/ +0x32664b3]
(In reply to Jan-Ivar Bruaroey [:jib] from comment #10)
> Odd, in comment 0 it's in the audio driver:
> >#04: mozilla::AudioCallbackDriver::DataCallback(float*, long)[/Users/mark/loop/gecko-dev/objdir-ff/dist/ +0x1ef727a]
> >#05: audiounit_output_callback[/Users/mark/loop/gecko-dev/objdir-ff/dist/ +0x32664b3]

It's always an audio driver for everything when there is at least one MediaStream that has a MediaStreamTrack that has audio. The AudioCallbackDriver is just running the graph to ensure audio latency is minimal.
I believe this doesn't currently block the tab sharing release as we're not hitting it with the newer sdk. Though platform will obviously want to fix this still.
No longer blocks: 1115336
Depends on: 1140030
Bug 1140030 has a testcase that triggers the same assertion, somewhat reliably. HTH.
Severity: critical → normal
backlog: --- → webRTC+
Rank: 35
Priority: -- → P3
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.