[Webkit-unassigned] [Bug 177526] [GTK] Segfault in WebPageProxy::setFindClient()

[bugzilla-daemon at webkit.org]

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

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcatanzaro at igalia.com
            Summary|[Gtk] Segfault in           |[GTK] Segfault in
                   |WebPageProxy::setFindClient |WebPageProxy::setFindClient
                   |()                          |()

--- Comment #1 from Michael Catanzaro <mcatanzaro at igalia.com> ---
The crash is certainly in the GTK API layer. webkitWebViewGetPage is returning *nullptr, which should never ever happen. If you find a way to reproduce this, that would be awesome.

webkitWebViewGetPage returns the result of webkitWebViewBaseGetPage, dereferenced. I'm a bit surprised it doesn't segfault right there, but I suppose a compiler optimization might be responsible for avoiding that.

webkitWebViewBaseGetPage just returns priv->pageProxy.get(), which is initialized in webkitWebViewBaseCreateWebPage. And pageProxy is a RefPtr, so it's cleared in finalize (not dispose) by the priv destructor. So, once set, it should be valid until the WebKitWebViewBase has been finalized. So I think that, somehow, webkit_web_view_get_find_controller was called before webkitWebViewBaseCreateWebPage.

Now, in the case we care about, where the WebKitWebViewBase is a WebKitWebView, webkitWebViewBaseCreateWebPage is only called by webkitWebViewCreatePage, which is only called by webkitWebContextCreatePageForWebView, which is always called in webkitWebViewConstructed. So this looks safe: there should be no way to get into this state where a WebKitWebView has no WebPageProxy, unless the WebKitWebViewBase has already been destroyed.

I was a bit suspicious that might happen when the WebKitWebView is finalized, but no: in WTFGType.h (where finalize is defined) we see that the private struct destructor is called before the parent class is finalized, not after. And that is the right order.

So I think it's most likely that a refcounting error elsewhere has caused pageProxy to be destroyed even while WebKitWebViewBase is still valid and still has it in a RefPtr.

What I also do not understand is how the backtrace goes from WebKit::WebPageProxy::didCommitLoadForFrame to g_object_unref -> webkitFindControllerDispose. I looked at all the load-changed signal handlers in eolie and didn't find anything suspicious. Maybe a 'bt full' could shed more light on this, or an unoptimized build... if you can manage to reproduce it again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170927/9967348e/attachment.html>