[Webkit-unassigned] [Bug 116672] WebKit2.WebContext register_uri_scheme does segfault

[bugzilla-daemon at webkit.org]

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

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcatanzaro at igalia.com

--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to Philip Chimento from comment #2)
> What's going wrong here is that the default WebContext object is destroyed
> in an atexit() handler. When that happens, the GDestroyNotify function
> passed to register_uri_scheme() is called, but at that point the Python or
> JS runtime has already been shut down, so it segfaults.
> 
> A library should definitely not register any atexit() handlers.

Easier said than done. :(

> Probably it
> should be OK to not destroy the default WebContext, since the memory will be
> reclaimed at the end of the process anyhow.

Problem is a mismatch between C++ best-practices, and GObject.

C++ allows static objects. Best practice is to only ever store trivially-destructible types into static objects. If you store something that's not trivially-destructible, then its destructor will be run in an exit handler. In WebKit cross-platform code, we ban exit-time destructors because they get executed in nondeterministic order on Windows.

But in the GTK/WPE-specific code, we've found cases where it's unavoidable. Bug #166029 comes to mind. C++ best practice is to leak the object to avoid an exit time destructor, but GObject classes expect to be disposed and finalized and do important things besides free memory when disposed/finalized. In this case, that was to close database handles. It could also be to shut down network connections, etc. (We also have a couple manual exit handlers too, but this isn't one of those.)

So if we want to leak the default web context, we have to make sure it's safe to do so. That means checking its dispose/finalize, and the destructors of all objects in its priv struct, to make sure each and every one of them is safe to skip. And then predicting the future to ensure that no destructors are ever added that would be unsafe to skip. It's a really hard problem. I know for starters that we'll run into problems because the default WebProcessPool won't be destroyed, and that is leak-checked, so you'll get a big warning in debug builds, for instance.

So not a simple problem at all. Not at all....

-- 
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/20181113/e0194694/attachment-0001.html>