1030934 - crashes in StreamTextureHost::Lock() due to SwapConsumer returning null (D3D11 compositor)

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect, P2)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

From a build from m-c 6-24, I get frequent crashes at:

>	xul.dll!mozilla::layers::StreamTextureHost::Lock() Line 863	C++
 	xul.dll!mozilla::layers::ImageHost::Composite(mozilla::layers::EffectChain & aEffectChain, float aOpacity, const mozilla::gfx::Matrix4x4 & aTransform, const mozilla::gfx::Filter & aFilter, const mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> & aClipRect, const nsIntRegion * aVisibleRegion, mozilla::layers::TiledLayerProperties * aLayerProperties) Line 84	C++
 	xul.dll!mozilla::layers::CanvasLayerComposite::RenderLayer(const nsIntRect & aClipRect, mozilla::gfx::vr::HMDInfo * aHMD) Line 121	C++

where abstractSurf is NULL.

I can reproduce it trivially by clearing cache and all other private data, then loading http://media.tojicode.com/q3bsp/ .  If I wait too long after browser startup, or if it's already loaded successfully once, then it loads fine.

This is the very first SwapConsumer that happens.  In SurfaceStream_TripleBuffer_Copy::SwapConsumer_NoWait, mStaging and mConsumer are both null.

Is it possible that the web page is creating a WebGL canvas context, but then not doing any drawing to it for a while -- but we still try to composite the canvas in the meantime, despite never having created any surfaces for it?

Comment 2

[Kelsey Gilbert [:jgilbert]]

Yep, my bad. Interesting that we have no tests for this.

First off, SwapConsumer is treated here as infallible, when it is not. We should fix this. When SwapConsumer fails in the general case, we should be continuing to show the previous frame. (The code here looks like it doesn't quite handle this well, but it seems like it works for now)

Ok, so if SwapConsumer returns null, and we don't have a previous frame, what should we do? It looks like the spec doesn't say anything here. [...] Nevermind, we just merged in a PR I wrote to clarify this: We present after resizes and context creation, so we should always have at blank first frame.

Comment 3

[Kelsey Gilbert [:jgilbert]]

Attachment: no-cons-frame

Comment 4

[Kelsey Gilbert [:jgilbert]]

(In reply to Jeff Gilbert [:jgilbert] from comment #3)
> Created attachment 8447514 [details] [diff] [review]
> no-cons-frame

This will stop the crash, but is technically not spec-compliant yet.

Comment 5

[Bas Schouten (:bas.schouten)]

Comment on attachment 8447514 [details] [diff] [review]
no-cons-frame

It's better than crashing still.

Comment 6

[Kelsey Gilbert [:jgilbert]]

 https://hg.mozilla.org/integration/mozilla-inbound/rev/b8e97a65002d

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b8e97a65002d