Bug 87912 – [chromium] Assertion failures during compositor startup in lost context situations

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Kenneth Russell]

Chromium bug http://code.google.com/p/chromium/issues/detail?id=121780 illustrates a situation where forcing a lost context provokes an assertion failure in the compositor during the next frame. Here is the stack trace:

ERROR: Failed to create vertex shader
/Users/kbr/src/chrome.git/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../platform/graphics/chromium/ProgramBinding.cpp(94) : unsigned int WebCore::ProgramBindingBase::createShaderProgram(WebCore::GraphicsContext3D *, const WTF::String &, const WTF::String &)
ASSERTION FAILED: m_program
/Users/kbr/src/chrome.git/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../platform/graphics/chromium/ProgramBinding.cpp(56) : void WebCore::ProgramBindingBase::init(WebCore::GraphicsContext3D *, const WTF::String &, const WTF::String &)
1   0x43db936 WebCore::ProgramBindingBase::init(WebCore::GraphicsContext3D*, WTF::String const&, WTF::String const&)
2   0x43cf8a9 WebCore::ProgramBinding<WebCore::VertexShaderPosTexTransform, WebCore::FragmentShaderRGBATexFlipAlpha>::ProgramBinding(WebCore::GraphicsContext3D*)
3   0x43ccde9 WebCore::ProgramBinding<WebCore::VertexShaderPosTexTransform, WebCore::FragmentShaderRGBATexFlipAlpha>::ProgramBinding(WebCore::GraphicsContext3D*)
4   0x43c0e8c WebCore::LayerRendererChromium::textureProgramFlip()
5   0x43bb438 WebCore::LayerRendererChromium::drawTextureQuad(WebCore::CCTextureDrawQuad const*)
6   0x43ba156 WebCore::LayerRendererChromium::drawQuad(WebCore::CCDrawQuad const*, WebCore::FloatRect const&)
7   0x43b9cb2 WebCore::LayerRendererChromium::drawRenderPass(WebCore::CCRenderPass const*)
8   0x445e42f WebCore::CCLayerTreeHostImpl::drawLayers(WebCore::CCLayerTreeHostImpl::FrameData const&)
9   0x44923cb WebCore::CCSingleThreadProxy::doComposite()
10  0x449052e WebCore::CCSingleThreadProxy::commitAndComposite()
11  0x449213e WebCore::CCSingleThreadProxy::compositeImmediately()
12  0x44463f6 WebCore::CCLayerTreeHost::composite()
13  0x3966833 WebKit::WebLayerTreeView::composite()
14  0x39c04d4 WebKit::WebViewImpl::composite(bool)
15  0x771c1ed RenderWidget::DoDeferredUpdate()
16  0x77202ee RenderWidget::DoDeferredUpdateAndSendInputAck()
17  0x772202c RenderWidget::AnimationCallback()

I don't know the best way to reliably reproduce this. I'm in the process of adding LayoutTests/platform/chromium/compositing/webgl-loses-compositor-context-2.html which used to provoke it in debug builds when run on MacBook Pros supporting dynamic GPU switching in Chrome (Early 2011 and later); however, it looks like the fix for http://code.google.com/p/chromium/issues/detail?id=121780 makes the assertion failure stop happening. Commenting out the fix for that bug may be the simplest way to reproduce the assertion on the affected hardware. Separately, we need to be able to test the lost context code path better on all hardware.

[Kenneth Russell]

I was wrong; the assertion failure is still happening even with the fix for http://code.google.com/p/chromium/issues/detail?id=121780 , so this is still an outstanding issue.

[James Robinson]

We could quite easily simulate this with a unit test that went through the compositor initialization with a mock GraphicsContext3D that lost its context at various points through the startup sequence.

[James Robinson]

Created attachment 145168 [details]
Patch

[Adrienne Walker]

Comment on attachment 145168 [details]
Patch

Oh, nice.  R=me.

[James Robinson]

Committed r119160: <http://trac.webkit.org/changeset/119160>