1399850 - Crash in [@ mozilla::layers::WebRenderLayerManager::SetLayerObserverEpoch ]

Status: RESOLVED DUPLICATE of bug 1391262

(Core :: Graphics: WebRender, defect, P3)

Description

[Darkspirit]

Nightly 57 x64 20170914100122 de_DE @ Debian Testing
Webrender + Layersfree + (sorry) GPU-Process

I get this crash signature (bp-ab3b5e99-2529-4ed7-9efd-b29450170914 for example) between bug 1397407 crashs.
Because I don't know if the GPU process (which is indispensable for the moment) is the cause, I file this bug.

Comment 1

[Calixte Denizet (:calixte)]

There are 25 crashes (from 6 installations) in nightly 57 starting with buildid 20170907220212.
:nical, could you investigate please ?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Most likely what's happening is the call at [1] is being made on a WebRenderLayerManager that was just created in the preceding call to mPuppetWidget->GetLayerManager(), and so the layer manager doesn't have a mWrChild created yet. That only happens when Initialize() is called on the WebRenderLayerManager.

This code has been problematic for a long time now, because InternalSetDocShellIsActive often gets called pretty early during tab creation, before it has a layer manager properly hooked up. I think the best way to resolve this once and for all is to add a method on PuppetWidget to get the layer manager if it exists, *without* creating it. And then in InternalSetDocShellIsActive we add a null guard.

[1] http://searchfox.org/mozilla-central/rev/6326724982c66aaeaf70bb7c7ee170f7a38ca226/dom/ipc/TabChild.cpp#2567

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Actually this doesn't make sense. The SetLayerObserverEpoch() call happens inside an |if (mCompositorOptions)| block but both the places that set mCompositorOptions also initialize the layer manager. So something else must be going on here.

Comment 4

[Darkspirit]

Today I got the crash from this bug together with:

* bug 1397407 = [@ mozalloc_abort | abort | core::option::expect_failed | webrender::resource_cache::ResourceCache::get_cached_image ]

* bug 1397220 = [@ mozilla::ipc::ProcessLink::SendMessage | IPC_Message_Name=PWebRenderBridge::Msg_SetDisplayList ]
> bp-e0ce68d2-cd84-4731-9beb-4ee460170914
> MOZ_CRASH(IPC message size is too large)

* (not reported) [@ mozilla::ipc::MessageChannel::Send [clone .cold.461] | mozilla::layers::PAPZCTreeManagerChild::SendUpdateZoomConstraints ]
> bp-ddf09ea4-998e-4300-83a1-d0e870170914
> MOZ_RELEASE_ASSERT(mWorkerThread == GetCurrentVirtualThread()) (not on worker thread!)

Comment 5

[Kartikaya Gupta (email:[e-mail])]

mystor, you've touched the docshell activation code recently. Any theories? If not I can put together a diagnostic patch to see if somehow we're getting mCompositorOptions set to something without the layer manager being created.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Oh, I see. All the crash reports have gfxCriticalNote annotations for [1]. Which means the WebRenderLayerManager initialization is failing (probably a dead/failed GPU process) but we carry on anyway, resulting in a fail when the docshell is activated.

[1] http://searchfox.org/mozilla-central/rev/6326724982c66aaeaf70bb7c7ee170f7a38ca226/gfx/layers/wr/WebRenderLayerManager.cpp#75

Comment 7

[Kartikaya Gupta (email:[e-mail])]

For now this is Linux only so dropping the priority.

Comment 8

[Sotaro Ikeda [:sotaro]]

All the crashe reports had the following error.

>  "GraphicsCriticalError 	|[C0][GFX1-]: Failed to create WebRenderBridgeChild. (t=0.345005) "

Comment 9

[Sotaro Ikeda [:sotaro]]

By comment 8, there is a case that WebRenderLayerManager::Initialize() failed to create WebRenderBridgeChild.

  https://dxr.mozilla.org/mozilla-central/source/gfx/layers/wr/WebRenderLayerManager.cpp#71

Comment 10

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Add WrBridge() checks in WebRenderLayerManager

Comment 11

[Sotaro Ikeda [:sotaro]]

bug 1391262 seems like dup of this bug. bug 1391262 might have a bit different signature.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 8910199 [details] [diff] [review]
patch - Add WrBridge() checks in WebRenderLayerManager

Review of attachment 8910199 [details] [diff] [review]:
-----------------------------------------------------------------

Do you understand why this crash might be happening? I feel like we should try and address the root cause - your patch will fix this particular instance of the crash but it will probably just crash later. If we actually have a tab that we're using with a WebRenderLayerManager on the content side but it's not attached to anything on the parent side that's kind of bad, and we should fall back to not using WebRender at all. But I don't know what kind of circumstances triggers this. It's possible somebody is just fiddling with random prefs on Linux and getting themselves in a bad state, which is why I didn't want to spend more time on this.

Comment 13

[Sotaro Ikeda [:sotaro]]

Okey, I am going to looking into more why the crash happened.