Firefox has been intermittently hanging for long periods of time (1 min+) lately. I caught today's hang in GDB. The browser was idle -- I was listening to music using the Flash player at http://swingadelic.com/video.html, but I was not interacting with my computer at all. All-threads stack trace is attached. It appears that thread 1 (the main thread) is blocked waiting for thread 12 to complete a SQLite operation: Thread 12 (etc.) sqlite3_step mozilla::storage::Connection::stepStatement(sqlite3_stmt*) mozilla::storage::AsyncExecuteStatements::executeStatement Thread 1 (etc.) SQLiteMutexAutoLock mozilla::storage::Connection::BeginTransactionAs mozStorageTransaction::mozStorageTransaction nsNavHistory::BeginUpdateBatch UpdateBatchScoper nsNavHistory::RunInBatchMode nsNavBookmarks::RunInBatchMode

Joe, I don't know if this is the same hang you've been seeing.

The statement which is executing in comment 12 is: (gdb) info frame Stack level 12, frame at 0x7f257f6fab70: rip = 0x7f259cd95f1e in sqlite3VdbeExec (/builds/slave/m-cen-lnx64-ntly/build/db/sqlite3/src/sqlite3.c:1399); saved rip 0x7f259cd8578d (gdb) p ((Vdbe*)(p))->zSql $23 = 0x7f25641995b0 "UPDATE moz_places SET frecency = ROUND(frecency * .975) WHERE frecency > 0"

(In reply to Justin Lebar [:jlebar] from comment #2) > The statement which is executing in comment 12 is: er...*thread* 12, not comment 12.

Taras, do you know if the SQLite hang detector would catch this? The long-running SQLite transaction is off the main thread, but it's blocking some main-thread action. I can't tell if the main-thread code has progressed far enough to trigger the long-sqlite hang detector or not.

I'm having some trouble unrolling this js stack. (gdb) call DumpJSSttack() outputs nothing.

I thought the write-ahead log was supposed to make large updates like this not block the whole database?

Isn't there already a bug on this?

Maybe bug 722188?

That's the one I was thinking of, yes.

Un-duping per bug 723611 comment 9.

I'm not sure if it's worth to keep this open, all the bugs are set as dependencies of bug 722188 that tracks practically all the stacks afaict. I'd probably re-dupe to it.

(In reply to Marco Bonardo [:mak] from comment #12) > I'm not sure if it's worth to keep this open, all the bugs are set as > dependencies of bug 722188 that tracks practically all the stacks afaict. > I'd probably re-dupe to it. Is that still the plan?

if you're fine with that, yes. I didn't see recent reports.

reduping, in future we should file a new bug if we hit a similar issue, since could have completely different origin.