[Webkit-unassigned] [Bug 166029] [GTK] SoupCookieJar is never released (resulting in sqlite temp files lying around)

[bugzilla-daemon at webkit.org]

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

--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
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. bug #163504 and bug #164303) 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.

-- 
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/20170115/167887fa/attachment.html>