Description of problem: Launched it. Version-Release number of selected component: devhelp-3.15.91-1.fc22 Additional info: reporter: libreport-2.4.0 backtrace_rating: 4 cmdline: devhelp crash_function: sqlite3_initialize executable: /usr/bin/devhelp kernel: 4.0.0-0.rc2.git0.1.fc22.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #1 sqlite3_initialize at sqlite3.c:126557 #2 openDatabase at sqlite3.c:129030 #3 WebCore::SQLiteFileSystem::openDatabase(WTF::String const&, sqlite3**, bool) at /lib64/libwebkit2gtk-4.0.so.37 #4 WebCore::SQLiteDatabase::open(WTF::String const&, bool) at /lib64/libwebkit2gtk-4.0.so.37 #5 WebKit::LocalStorageDatabaseTracker::openTrackerDatabase(WebKit::LocalStorageDatabaseTracker::DatabaseOpeningStrategy) at /lib64/libwebkit2gtk-4.0.so.37 #6 WebKit::LocalStorageDatabaseTracker::importOriginIdentifiers() at /lib64/libwebkit2gtk-4.0.so.37 #7 WTF::GMainLoopSource::voidCallback() at /lib64/libjavascriptcoregtk-4.0.so.18 #8 WTF::GMainLoopSource::voidSourceCallback(WTF::GMainLoopSource*) at /lib64/libjavascriptcoregtk-4.0.so.18 #13 WTF::threadEntryPoint(void*) at /lib64/libjavascriptcoregtk-4.0.so.18 #14 WTF::wtfThreadEntryPoint(void*) at /lib64/libjavascriptcoregtk-4.0.so.18
Created attachment 1001406 [details] File: backtrace
Created attachment 1001407 [details] File: cgroup
Created attachment 1001408 [details] File: core_backtrace
Created attachment 1001409 [details] File: dso_list
Created attachment 1001410 [details] File: environ
Created attachment 1001411 [details] File: limits
Created attachment 1001412 [details] File: maps
Created attachment 1001413 [details] File: open_fds
Created attachment 1001414 [details] File: proc_pid_status
Created attachment 1001415 [details] File: var_log_messages
I've filed https://bugzilla.gnome.org/show_bug.cgi?id=746166 to disable local storage in devhelp. Anyway, since the crash is inside sqlite3_initialize, I think this should be assigned to the sqlite maintainers to investigate. Or, it could be assigned to the ABRT developers as a reminder that ABRT needs to update debuginfo before filing bug reports.
*** Bug 1207221 has been marked as a duplicate of this bug. ***
I'm assigning this bug to sqlite because: a) The crash is deep in sqlite. b) I don't think we're misusing sqlite's thread-safety guarantees (see WebKit bug #143245).
*** Bug 1217952 has been marked as a duplicate of this bug. ***
*** Bug 1228391 has been marked as a duplicate of this bug. ***
Let's explicitly open all databases in serialized mode, just in case another library is misbehaving and changing the default mode for the entire process. Then if that doesn't fix the bug, we know for sure it is an SQLite bug.
webkitgtk4-2.8.3-3.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/webkitgtk4-2.8.3-3.fc22
OK, the patch does not work. This must be an SQLite bug after all. We're opening the database in serialized mode, and SQLite promises that this is completely thread-safe, but crashes anyway when used from multiple threads.
Oh, that's why nobody responded to the bug report last time, I picked the wrong sqlite package. :D
I think this is because the sqlite3_initialize function is not thread-safe, in violation of the documentation. The backtraces I have from crashing devhelp all point at sqlite3_initialize -> sqlite3MutexInit attempting to call a null pointer while there is a concurrent sqlite3_initialize -> sqlite3MutexAlloc. Thread 1 (Thread 0x7ff2ed7fe700 (LWP 7573)): #0 0x0000000000000000 in ?? () #1 0x00007ff2fe695612 in sqlite3MutexInit () at sqlite3.c:19158 #2 sqlite3_initialize () at sqlite3.c:62618 #3 0x00007ff2fe733769 in openDatabase (zFilename=0x7ff2ee7da0b0 "/home/jan/.local/share/webkitgtk/localstorage/StorageTracker.db", ppDb=0x7ff2ee7ed0f8, flags=6, zVfs=0x0) at sqlite3.c:130644 #4 0x00007ff305375ca5 in ?? () from /usr/lib/libwebkit2gtk-4.0.so.37 Thread 3 (Thread 0x7ff2edfff700 (LWP 7572)): #0 sqlite3MemMalloc (nByte=40) at sqlite3.c:17137 #1 0x00007ff2fe6792a8 in mallocWithAlarm (pp=<synthetic pointer>, n=<optimized out>) at sqlite3.c:20801 #2 sqlite3Malloc (n=<optimized out>) at sqlite3.c:20832 #3 0x00007ff2fe6833aa in sqlite3MallocZero (n=40) at sqlite3.c:21130 #4 pthreadMutexAlloc (iType=<optimized out>) at sqlite3.c:19627 #5 0x00007ff2fe695de7 in sqlite3MutexAlloc (id=1) at sqlite3.c:19200 #6 sqlite3_initialize () at sqlite3.c:62637 #7 0x00007ff2fe733769 in openDatabase (zFilename=0x7ff2ee7dc0b0 "/home/jan/.local/share/webkitgtk/localstorage/StorageTracker.db", ppDb=0x7ff2ee7ed018, flags=6, zVfs=0x0) at sqlite3.c:130644 #8 0x00007ff305375ca5 in ?? () from /usr/lib/libwebkit2gtk-4.0.so.37 So I guess a workaround would be to call sqlite3_initialize early, before spawning any other database-using threads.
Thanks Jan. I agree with your assessment. For WebKit, I will work around this with an explicit call to sqlite3_initialize, protected by std::call_once. I will leave this bug open since that is only a workaround.
This has apparently been fixed upstream: http://news.gmane.org/gmane.comp.db.sqlite.general
Specifically: https://www.sqlite.org/src/info/11a9a786ec06403a
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.