[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 #12 from Michael Catanzaro <mcatanzaro at igalia.com> ---
This implementation of NetworkStorageSession::defaultStorageSession fixes the bug:

NetworkStorageSession& NetworkStorageSession::defaultStorageSession()
{
    if (!defaultSession()) {
        defaultSession() = std::make_unique<NetworkStorageSession>(SessionID::defaultSessionID(), nullptr);
        std::atexit([] {
            // Ensure cookie storage is closed cleanly even though the default session is NeverDestroyed.
            g_object_unref(defaultSession()->m_cookieStorage.get());
            g_object_unref(defaultSession()->m_cookieStorage.get());
            g_object_unref(defaultSession()->m_cookieStorage.leakRef());
        });
    }
    return *defaultSession();
}

It requires one unref for the SoupCookieJar owned by the default NeverDestroyed NetworkStorageSession, another unref because it's also owned by the SoupSession owned by the default NeverDestroyed SoupNetworkSession, and a third unref because it's also owned by... I dunno, something else, haven't figured that out.

The first thing I would do to simplify this is have the NetworkStorageSession access its SoupCookieJar via the SoupNetworkSession instead of keeping its own reference.

Unfortunately we know we for sure cannot destroy the default SoupSession, because that has caused nasty exit handler crashes in the past. So if we want to destroy the SoupCookieJar, then we have no choice but to unref it from somewhere it is not owned, to balance the ref owned by the default SoupSession that we know will never be destroyed.

Alternatively, we could try to sqlite3_close() the database manually. This would require exposing the private SQLiteDatabase object owned by WebKitSoupCookieJarSqlite (not desirable) or else adding some way to tell WebKitSoupCookieJarSqlite to close its database even though it's not being destroyed. This seems like the best approach.

-- 
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/20170702/0f4c174e/attachment.html>