Backtrace (devided in two parts) This is where I called abort from handler on main thread: #0 0x00007f2203787425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f220378ab8b in __GI_abort () at abort.c:91 #2 0x0000000000412d80 in sigH (id=34, info=0x7f21f6e8e1b0) at /home/balazs/webkit/Tools/WebKitTestRunner/qt/main.cpp:107 #3 <signal handler called> This is the icon database thread: #4 0x00007f2203e1f40d in fsync () at ../sysdeps/unix/syscall-template.S:82 #5 0x00007f220889ae99 in full_fsync (fd=16, fullSync=0, dataOnly=0) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:27732 #6 0x00007f220889aee9 in unixSync (id=0x7f21a8001b00, flags=2) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:27780 #7 0x00007f220889218a in sqlite3OsSync (id=0x7f21a8001b00, flags=2) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:14334 #8 0x00007f22088a357c in syncJournal (pPager=0x7f21a8001928, newHdr=0) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:40740 #9 0x00007f22088a56a7 in sqlite3PagerCommitPhaseOne (pPager=0x7f21a8001928, zMaster=0x0, noSync=0) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:42698 #10 0x00007f22088ae6ac in sqlite3BtreeCommitPhaseOne (p=0x7f21a8000908, zMaster=0x0) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:50663 #11 0x00007f22088bc524 in vdbeCommit (db=0x7f21a8000e98, p=0x7f21a800e558) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:59368 #12 0x00007f22088bce3b in sqlite3VdbeHalt (p=0x7f21a800e558) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:59780 #13 0x00007f22088c17ed in sqlite3VdbeExec (p=0x7f21a800e558) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:63650 #14 0x00007f22088bf0a5 in sqlite3Step (p=0x7f21a800e558) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:61240 #15 0x00007f22088bf291 in sqlite3_step (pStmt=0x7f21a800e558) at /home/balazs/repo/qt5/qtbase/src/3rdparty/sqlite/sqlite3.c:61313 #16 0x00007f2208251196 in WebCore::SQLiteStatement::step (this=0x7f21f6e8ea70) at /home/balazs/webkit/Source/WebCore/platform/sql/SQLiteStatement.cpp:110 #17 0x00007f220825142d in WebCore::SQLiteStatement::executeCommand (this=0x7f21f6e8ea70) at /home/balazs/webkit/Source/WebCore/platform/sql/SQLiteStatement.cpp:146 #18 0x00007f220824f4da in WebCore::SQLiteDatabase::executeCommand (this=0x1abd1d0, sql="CREATE TABLE PageURL (url TEXT NOT NULL ON CONFLICT FAIL UNIQUE ON CONFLICT REPLACE,iconID INTEGER NOT NULL ON CONFLICT FAIL);") at /home/balazs/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:262 #19 0x00007f22085c8b21 in WebCore::createDatabaseTables (db=...) at /home/balazs/webkit/Source/WebCore/loader/icon/IconDatabase.cpp:1082 #20 0x00007f22085c93c8 in WebCore::IconDatabase::performOpenInitialization (this=0x1abce90) at /home/balazs/webkit/Source/WebCore/loader/icon/IconDatabase.cpp:1165 #21 0x00007f22085c8799 in WebCore::IconDatabase::iconDatabaseSyncThread (this=0x1abce90) at /home/balazs/webkit/Source/WebCore/loader/icon/IconDatabase.cpp:1028 #22 0x00007f22085c8526 in WebCore::IconDatabase::iconDatabaseSyncThreadStart (vIconDatabase=0x1abce90) at /home/balazs/webkit/Source/WebCore/loader/icon/IconDatabase.cpp:979 #23 0x00007f220b18bbfd in WTF::threadEntryPoint (contextData=0x1abd4a0) at /home/balazs/webkit/Source/WTF/wtf/Threading.cpp:69

It does not seem to be at the teardown of the main thread so I have no idea what is wrong here (other than it can be a bug in sqlite3).

(In reply to comment #2) > It does not seem to be at the teardown of the main thread so I have no idea what is wrong here (other than it can be a bug in sqlite3). The only thing that changed recently is that we tear it down correctly when the web process closes, I'm not even sure if that code runs on shutdown. Look there: http://trac.webkit.org/changeset/132534 Other than that, if something is sending that signal, then the problem is that it isn't handled, no? Isn't it some weird permission problem on your machine, or some patch lying around in your tree?

(In reply to comment #3) > (In reply to comment #2) > > It does not seem to be at the teardown of the main thread so I have no idea what is wrong here (other than it can be a bug in sqlite3). > > The only thing that changed recently is that we tear it down correctly when the web process closes, I'm not even sure if that code runs on shutdown. > No it runs on initialization. > Look there: http://trac.webkit.org/changeset/132534 > > Other than that, if something is sending that signal, then the problem is that it isn't handled, no? > Isn't it some weird permission problem on your machine, or some patch lying around in your tree? These signals are designed for user space usage, the kernel does not send them to any process. There is no patch of mine involved in this. I forgot to mention that it's a flaky bug, I jut run one test and half the time it crashes. I checked and the sender pid is WTR itself, so it must be some library who triggers it via sigqueue, but than why that library doesn't handle it? I will take a look at permissions and ask somebody to take a try so we will know whether it's only a local issue.

It seems like it's run-webkit-tests who kill us for some reason and the backtrace is just the result of that. IconDatabase::close is not running in that case while it does if I launch WTR from the command line.

I debugged nrwt and there I also found that it detects the driver as crashed with signal 34 (SIGRTMIN). The WebpageIcons.db file is 0 bytes in this case and there is a WebpageIcons.db-journal file (normally it has some content and no journal is present). The path from nrwt is always like /tmp/WebKitTestRunner-<randomhash> with the same permissions. The strange thing is that even if I set such a path to DUMPRENDERTREE_TMP, I can nearly never reproduce it by calling WTR from command line. Maybe it has related to how nrwt use the driver, i.e. that it listen to it's output channels? Not so convincing... Probably something is wrong with the way sqlite use fsync. I also tried building qt with -system-sqlite, but it didn't help. Anyway, this bug is way beyond WebKit.

The patch in bug 100274 fixes it. A similar change was also made in the past: http://trac.webkit.org/changeset/111526. *** This bug has been marked as a duplicate of bug 100274 ***

It turned out that the real time signal is only hit with the nvidia proprietary driver. Michael Pruett informed me about his finding, which is that the driver's pthread_atfork handler incorrectly manipulating shared process state. This is causing trouble if we wait long in a syscall like in the case of fsync. I change the status to invalid as this is an nvidia driver bug.