[Webkit-unassigned] [Bug 92753] [Qt] Snowshoe desktop crashes when opening a new tab

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=92753


Jesus Sanchez-Palencia <jesus at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kbalazs at webkit.org




--- Comment #4 from Jesus Sanchez-Palencia <jesus at webkit.org>  2012-08-06 11:51:32 PST ---
This issue persists even after the roll out of https://bugs.webkit.org/show_bug.cgi?id=93077 , so I'll brief you guys a bit after I had a closer look into this. I will be over-explicative just because I'm not familiar with this code path and I will this as an exercise. :)

As Alexis pointed out, the problem is the ASSERT(layer) we are reaching at Source/WebKit2/UIProcess/WebLayerTreeRenderer.cpp:335 . This is caused because when LayerTreeCoordinatorProxy::setCompositingLayerChildren is called for the new tab, the WebLayerTreeRenderer is not active yet. Therefore, the WebLayerTreeRenderer::appendUpdate calls don't do anything and setLayerChildren calls aren't queued to be dispatched by the next WebLayerTreeRenderer::syncRemoteContent.

This is all happening on the UIProcess side and the reason why we don't see this crash when we first start snowshoe is because when the first tab is created the following call stack happens before any LayerTreeCoordinatorProxy or WebLayerTreeRenderer calls:

QQuickWebPage::updatePaintNode
WebKit::QtWebPageSGNode::setRenderer

setRenderer creates a new ContentsSGNode that makes the renderer active.

When investigating why the WebProcess is sending messages to the UIProcess, triggering LayerTreeCoordinatorProxy::setCompositingLayerChildren even when the UIProcess is clearly not ready yet (no QtWebPageSGNode::setRenderer calls), I realized that the following call flow was happening on the WebProcess side:

WebKit::DrawingAreaImpl::sendDidUpdateBackingStoreState() 
WebKit::LayerTreeCoordinator::forceRepaint() 
WebKit::LayerTreeCoordinator::flushPendingLayerChanges()

This last function, flushPendingLayerChanges, is the one sending messages from the WebProcess to the UIProcess.

Reading LayerTreeCoordinator made me realize that perhaps we are missing a check to m_waitingForUIProcess somewhere, like the one in LayerTreeCoordinator::performScheduledLayerFlush. In fact, adding an early return to LayerTreeCoordinator::forceRepaint() fixes the crash. I haven't uploaded a patch for this because it feels wrong to early return like that in forceRepaint since the comments on this function say we use it exactly when "we are not waiting for a UIProcess to reply nicely."...

What do you guys think?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.