[Webkit-unassigned] [Bug 143245] Crash when WebCore::SQLiteFileSystem::openDatabase is called from multiple threads

[bugzilla-daemon at webkit.org]

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

--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Different but very related issue: I notice that one WebProcessPool is always leaked (using a debug build) when starting any application that uses WebKit, sometimes two. I never bothered to track it down, but surely it is that inspector "context." I don't think it's OK for WebInspectorProxy::inspectorProcessPool to intentionally leak the inspector context because WebProcessPool is fast-allocated. Also, WebInspectorProxy::inspectorProcessPool is not thread-safe; I presume the double leak occurs when multiple web processes are started at once. In platform-specific code I would fix that using GOnce and a RefPtr, like we do for the default web context, but I'm not sure what the appropriate idiom would be in WebInspectorProxy.cpp.

Maybe I should file another bug for this, but I guess it may be obsoleted by a fix for this bug.

(In reply to comment #2)
> I also wonder if we should avoid creating the local storage database when
> localStorage is disabled in settings, but that would be a different issue.

Yes....

Regarding thread safety: https://sqlite.org/threadsafe.html

In particular, "In serialized mode, SQLite can be safely used by multiple threads with no restriction" and "The default mode is serialized." Hm. I did a few git greps and am pretty sure we never change the default mode, which suggests this may be a bug in SQLite. It would probably be good to explicitly select the threading mode we need, because the default can be changed when compiling sqlite3, so we don't actually know for sure which mode we're using. I presume all sane Linux distros will default to serialized mode, though.

-- 
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/20150404/cdf76131/attachment-0001.html>