<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] SoupCookieJar is never released (resulting in sqlite temp files lying around)"
href="https://bugs.webkit.org/show_bug.cgi?id=166029#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] SoupCookieJar is never released (resulting in sqlite temp files lying around)"
href="https://bugs.webkit.org/show_bug.cgi?id=166029">bug 166029</a>
from <span class="vcard"><a class="email" href="mailto:mcatanzaro@igalia.com" title="Michael Catanzaro <mcatanzaro@igalia.com>"> <span class="fn">Michael Catanzaro</span></a>
</span></b>
<pre>The problem (after the recent cookie storage refactor in trunk) is that NetworkStorageSession::defaultSession is never destroyed:
static std::unique_ptr<NetworkStorageSession>& defaultSession()
{
ASSERT(isMainThread());
static NeverDestroyed<std::unique_ptr<NetworkStorageSession>> session;
return session;
}
NetworkStorageSession& NetworkStorageSession::defaultStorageSession()
{
if (!defaultSession())
defaultSession() = std::make_unique<NetworkStorageSession>(SessionID::defaultSessionID(), nullptr);
return *defaultSession();
}
This is a problem we have again, and again, and again (e.g. <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Default WebKitWebContext is always leaked"
href="show_bug.cgi?id=163504">bug #163504</a> and <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [GTK] BadDamage X Window System error in WebKit::AcceleratedBackingStoreX11::update when called from WebPageProxy::exitAcceleratedCompositingMode"
href="show_bug.cgi?id=164303">bug #164303</a>) and just don't know how to solve. It's a best-practices clash between C++ exit time destructors, C++ smart pointers, and GObject. In C++ it is an antipattern to ever destroy a static object, since exit-time destructors are a perennial source of crashes, so we use NeverDestroyed to ensure we leak these objects and to indicate that it is intentional. But, repeatedly, we find that the correctness of our code depends on destroying some GObject that we store in a GRefPtr inside a NeverDestroyed object, ensuring that the GObject never gets unreffed when we really need it to.
It's not even really a problem specific to GObject. If a big object is declared with NeverDestroyed, that means the destructors of all its member variables, and the members' members, and so on, never run. Nobody is likely to check a big tree of data members to make sure the destructors are not doing anything that really needs to happen at exit time.
The only clear options are to (a) get rid of the use of NeverDestroyed and hope for the best, or (b) set up an exit handler to manually unref the GObject. In general, both are poor choices. In general, GObjects assume that they will always be freed and may rightfully do important stuff in dispose and finalize, so we really shouldn't be leaking them.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>