1249656 - Firefox crashes when creating a new tab while tab sharing

Status: RESOLVED INCOMPLETE

(Hello (Loop) :: Client, defect)

Description

[Chris Rafuse :crafuse]

Firefox 44.0.2 on Windows 8.1 crashes the Hello link generator either when creating new tabs manually or by link.

Two crash reports here: 
first crash
https://crash-stats.mozilla.com/report/index/3f00f2b2-3ae8-4fa8-a0fc-038762160218
second crash
https://crash-stats.mozilla.com/report/index/56a30bc6-7cf3-4a9b-99ce-344302160218

Comment 1

[Ian Bicking (:ianbicking)]

Maire: because this is a crash I am guessing that this is WebRTC-related, is there someone on your team that can understand the crash report?

Comment 2

[Maire Reavy [:mreavy]]

This crash looks to be somewhere in the compositor (not directly WebRTC); needinfoing nical for deeper analysis and further triage.

Nical - Note that tab-capture, used with Hello, renders tabs into canvases to use as video sources.

Thanks

Comment 3

[Nicolas Silva [:nical]]

I didn't have time to make a significant breakthrough here, and I am going to be on PTO for a bit more than a week starting tomorrow, so bouncing the needinfo to Bas.
The interaction between video and canvases hints that the issue might be related to using a a D3D texture on the wrong device (if I remember correctly we have one D3D device for the main thread (where canvas lives) and a separate one for the ImageBridge which handles passing video stuff through to the compositor). CairoIamge is supposed to prevent this kind of mistake by associating its textures with an IPC worwarder (basically we have one forwarder for the main thread and one for the ImageBridge), but there could be something messing up in there that I missed.

Comment 4

[Nicolas Silva [:nical]]

By the way, For whoever gets to look at next: I got confused when looking into this because CairoImage was recently renamed into SourceSurfaceImage, which makes sense but is good to know when looking up bits of the stacktraces.

Comment 5

[Bas Schouten (:bas.schouten)]

Matt might have ideas about this, I don't know terribly much about the interaction between video and canvas. But if Matt doesn't have any immediate ideas I can look at it.

Comment 6

[Matt Woodrow (:mattwoodrow)]

The only thing that stands out is that the main thread is currently within a CResource<ID3D11Resource>::Map call, and the image bridge (crashing thread) has it's SourceSurface mapped.

The stacks are a bit broken, but it seems at least possible that we've mapped the same surface twice on different thread. Debugging the dump in visual studio would help.

It also seems like we're using the d2d device on multiple threads here.

The upload (which is what is crashing) should be on the image bridge specific device, exactly as nical described. I can't see any obvious flaws in this code.

We always upload by mapping the SourceSurface, and I can't see anything stopping this from happening using the same d2d/d3d device as the main thread uses. This isn't the bit that's crashing, but I think it's still likely an issue.

Want to look at the minidump to confirm the d2d race Bas?

Comment 7

[Bas Schouten (:bas.schouten)]

We can't confirm the race from the minidump but it seems likely from the code. As far as I can tell from the code on trunk this problem shouldn't be occurring on trunk, if it is we should have another look at that.

Comment 8

[Mark Banner (:standard8)]

Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.