This bug is for crash report bp-cf8567ea-bb52-42c2-9b20-a86e90191128.

Top 10 frames of crashing thread:

0 xul.dll mozilla::ipc::FatalError ipc/glue/ProtocolUtils.cpp:165
1 xul.dll mozilla::ipc::IProtocol::HandleFatalError ipc/glue/ProtocolUtils.cpp:404
2 xul.dll static bool mozilla::ipc::IPDLParamTraits<mozilla::layers::TimedTexture>::Read ipc/ipdl/LayersMessages.cpp
3 xul.dll static bool mozilla::ipc::IPDLParamTraits<nsTArray<mozilla::layers::TimedTexture> >::Read ipc/glue/IPDLParamTraits.h:189
4 xul.dll static bool mozilla::ipc::IPDLParamTraits<mozilla::layers::OpUseTexture>::Read ipc/ipdl/LayersMessages.cpp:12990
5 xul.dll static bool mozilla::ipc::IPDLParamTraits<mozilla::layers::CompositableOperationDetail>::Read ipc/ipdl/LayersMessages.cpp:13878
6 xul.dll mozilla::ipc::IPDLParamTraits<mozilla::layers::CompositableOperation>::Read ipc/ipdl/LayersMessages.cpp:13969
7 xul.dll mozilla::ipc::IPDLParamTraits<nsTArray<mozilla::layers::CompositableOperation> >::Read ipc/glue/IPDLParamTraits.h:189
8 xul.dll mozilla::layers::PImageBridgeParent::OnMessageReceived ipc/ipdl/PImageBridgeParent.cpp:349
9 xul.dll void mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2130

these crash reports are spiking up in nightly 72.0a1 since build 20191121214422 on windows.

the crash signature is covering multiple different issues - i'm filing this report just for the crashes containing IPCFatalErrorMsg Error deserializing 'textureParent' (PTexture) member of 'TimedTexture': https://crash-stats.mozilla.com/search/?ipc_fatal_error_msg=%3DError%20deserializing%20%27textureParent%27%20%28PTexture%29%20member%20of%20%27TimedTexture%27&build_id=%3E%3D20191121214422&product=Firefox&date=%3E%3D2019-11-01#crash-reports

those crashes all come with moz crash reason MOZ_CRASH(IPC FatalError in the parent process!) too.
a potential regression range based on the first affected buildid is https://mzl.la/2XRUFOU.
url correlations show that urls most prone to crashing in this fashion are various different gaming sites.

Sotaro, does this sound like something you are able to look into? (Judging by ImageBridge)

OK, I take a look.

|[G0][GFX1-]: TextureHost creation failure type=12

Majority of reports have the above GraphicsCriticalError. type=12 means TSurfaceDescriptorGPUVideo.

(In reply to Sotaro Ikeda [:sotaro] from comment #3)

|[G0][GFX1-]: TextureHost creation failure type=12

The log was added in Bug 1564667 for Bug 1562616 . Bug 1562616 is similar to this bug.

Bug 1562616 made GPUVideoTextureHost not to fail to create. But Bug 1577336 made that GPUVideoTextureHost creation could fail.

From comment 5, crash that has "TextureHost creation failure type=12" error log seems to be caused by Bug 1577336.

:handyman, Bug 1577336 seems to cause the crash of comment 4. Can you take the bug?

Yes, this must be the lookup of a TextureHostD3D11 variant of GPUVideoTextureHost failing in the plugin case here [1]. I need to make that infallible.

[1] https://searchfox.org/mozilla-central/rev/d69bff9bdb2dcf1788eec6232b21eb3eec342799/gfx/layers/composite/TextureHost.cpp#337

Would backing out bug 1577336 be an option at least for 72?

I have a simple patch that creates a "NullPluginTextureHost" when the lookup fails. This makes the behavior adjacent to the GPUVideoTextureHost infallible, but I can't find a way to reproduce the failure locally so I'm unsure of it. I'm still playing with various situations to try to repro.

I think the crash is rare enough (for one, it requires Flash use) and we are close enough to a fix that its best to leave the original async rendering patch. My NullPluginTextureHost is currently "minimal" but I think I can make it duplicate all of the degenerate behavior in GPUVideoTextureHost, which would give more assurance that it would behave at least as well as that class. This is easy to do but might be needless clutter in NullPluginTextureHost. But that's a small price to pay.

I'll post a patch that does this today but it won't get approved and landed before the merge. I'm expecting to uplift it.

(In reply to David Parks (dparks) [:handyman] from comment #10)

I think the crash is rare enough (for one, it requires Flash use) and we are close enough to a fix that its best to leave the original async rendering patch.

the issue is accounting for 25% of reported browser crashes on 72.0b at the moment, so based on volume it's certainly a top crasher.

If the D3D11TextureData backing the plugin variant of a GPUVideoTextureHost is requested, but the ImageBridge has already released or lost it then, instead of null, we now return a NullPluginTextureHost in order to avoid IPDL serialization failure down the line. This mirrors the degenerate case of RemoteVideoDecoder behavior, indroduced to fix the same issue with that variant of GPUVideoTextureHost, in bug 1562616.

FYI, it seems the reason I couldn't reproduce this is that the issue in bug 1600595 was always happening first -- this issue seems to follow almost every time. I've now been able to see this crash by fixing that bug. I've since tested with both this patch and the one from 1600595, and it seems to fix the crash as hoped.

For some reason the crash volume for both this and bug 1600595 has dropped considerably on nightly this week. Beta is badly affected though, even with a partial rollout, and I'm holding off on the full rollout because of this crash.
Attaching a backout patch against beta in case the fix doesn't make it in time for the next build (Monday at 04:00 UTC).

Fixed via backout for 72.0b4. 73+ remain affected.
https://hg.mozilla.org/releases/mozilla-beta/rev/3af5f7e1bd23

Backed out changeset 1644a92ede46 (Bug 1600032) for causing build bustages on ImageBridgeParent.cpp. CLOSED TREE

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=280940174&resultStatus=testfailed%2Cbusted%2Cexception&revision=1644a92ede46ec78429edd7d7c5381ef30fcfdee

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=280940193&repo=autoland&lineNumber=32698

Backout: https://hg.mozilla.org/integration/autoland/rev/4d1de8c70a1c7c13a8b3b83faff2a9d9738f6cc0

Trying again with fix for updated virtual function.

https://hg.mozilla.org/mozilla-central/rev/05a0c8c33bc4

Use the new utility function, introduced in Part 3, to implement async plugin surface's read to CPU texture.

Depends on D57563

Comment on attachment 9116564 [details]
Bug 1600032: Part 5 - Make RecvReadbackAsyncPluginSurface use ReadbackTexture r=mattwoodrow!

Revision D57564 was moved to bug 1600595. Setting attachment 9116564 [details] to obsolete.

Please specify a root cause for this bug. See :tmaity for more information.