[Webkit-unassigned] [Bug 177577] REGRESSION(2.18.0): [GTK] Crash in WebKitWebContext disposal

[bugzilla-daemon at webkit.org]

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

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugs-noreply at webkitgtk.org,
                   |                            |mcatanzaro at igalia.com
          Component|WebKit2                     |WebKit Gtk
            Summary|Crash/regression 2.18 on    |REGRESSION(2.18.0): [GTK]
                   |webkitgtk disposal          |Crash in WebKitWebContext
                   |                            |disposal

--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Just for future reference: the secret to getting a timely reply is to select the 'WebKit Gtk' component, as otherwise it's just luck if we ever see the bug. I know that's not obvious; sorry about that. :(

There's no new auto-cleanup mechanism.

As for "what's the correct way to destroy/dispose webkit/webview?"... normally GTK+ will do that for you: WebKitWebView comes with a floating ref that will be sunk when you add it to the widget hierarchy, so you can forget about destroying it manually. I imagine Eclipse is probably not using a real GTK+ widget hierarchy, though, so you can just call g_object_unref() directly to destroy it. You also first have to call g_object_ref_sink() after creating the WebKitWebView, if you are not going to be adding it to a widget hierarchy, to sink the floating ref.

Now, on to this bug....

I'm not sure if this is a bug in WebKit or in Eclipse. Adding an extra ref to your WebKitWebView, ensuring it gets leaked, fixed the issue for you because WebKitWebView refs its WebKitWebContext, so the WebKitWebContext never gets destroyed. The fact that it's being destroyed in an exit handler in your backtrace indicates that you're using the default WebKitWebContext, so another workaround you could use would be to not do that: create your own WebKitWebContext, use it when creating your WebKitWebViews, and unref it when you want to, rather than letting WebKit do it badly.

Now, the default WebKitWebContext gets freed in an exit handler because it's a C++ static object (declared in createDefaultWebContext() in WebKitWebContext.cpp), and exit handlers are where static objects get freed. It's good practice to always leak such objects, because running C++ destructors in exit handlers leads to lots and lots of crashes in practice. This has been a major source of bugs for us in the past (and present, e.g. bug #176490). If objects just free memory in its dispose/finalize or its C++ destructor, then it's no big deal, because that's not needed when the program is terminating anyway, but sometimes often do important things in dispose/finalize that need to happen. (See bug #166029 for a recent example of this.)

One option is that, instead of trying to paper over this problem by trying to fix this particular crash, we should probably always leak the default WebKitWebContext. This means we'll consequently to remove WebProcessPool from our leak tracking pool (see also: bug #163504).

On the other hand, this crash looks like it might not even be related to being run in an exit handler. We'd need a better backtrace ('bt full') to be sure, but it looks like the WebKitWebContext's WebCookieManagerProxy has somehow been destroyed before its WebProcessPool. It's supposed to happen in reverse order, because the WebProcessPool is declared first in the priv struct, meaning it is destroyed last. Does Eclipse use WebCookieManagerProxy directly, and if so, is it possible that Eclipse has some refcounting mistake with it? That seems most likely, as otherwise I'm surprised that no other developers have reported this issue yet.

-- 
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/20171026/1e5888f8/attachment.html>