[Webkit-unassigned] [Bug 151139] [GTK] Web Process crashes on reparenting a WebView with AC mode on

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Mario Sanchez Prada <mario at webkit.org> ---
I might be doing something wrong, because the backtrace I get by setting GDK_SYNCHRONIZE=1 is pretty much identical to the one I already posted... :/

Anyway, looking deeper with gdb, the problem seems to start with this:

    void DrawingAreaImpl::enterAcceleratedCompositingMode(GraphicsLayer* graphicsLayer)
    {
        m_exitCompositingTimer.stop();
        m_wantsToExitAcceleratedCompositingMode = false;

        m_webPage.send(Messages::DrawingAreaProxy::WillEnterAcceleratedCompositingMode(m_backingStoreStateID));

        ASSERT(!m_layerTreeHost);

        m_layerTreeHost = LayerTreeHost::create(&m_webPage);
    #if USE(TEXTURE_MAPPER) && PLATFORM(GTK)
        if (m_nativeSurfaceHandleForCompositing)
            m_layerTreeHost->setNativeSurfaceHandleForCompositing(m_nativeSurfaceHandleForCompositing);
    #endif
        [...]
    }

It looks like the call m_layerTreeHost->setNativeSurfaceHandleForCompositing(m_nativeSurfaceHandleForCompositing) is happening over a handle that is not valid, hence the BadDrawable error later on when calling XGetWindowAttributes() from WebCore::GLContextGLX::createWindowContext().

Carlos, does this ring any bell? Could it be possible that there's a race condition between consecutive calls to DrawingAreaImpl::enterAcceleratedCompositingMode and DrawingAreaImpl::exitAcceleratedCompositingMode(), for instance, that might be causing that a rogue handler ID is kept there?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151111/658ee652/attachment-0001.html>