Gregory, I'm regularly getting aborts when closing the browser like below: Assertion failure: !connections[i]->ConnectionReady(), at /Users/ehsanakhgari/moz/mozilla-central/storage/src/mozStorageService.cpp:828 Does that mean that your event loop spinning hack doesn't work all the time?

Ehsan: is this a quit very soon after starting the browser, or a long-lived session? What build? Could you crank datareporting.healthreport.logging.console{Level,Enabled} and grab more console output?

(In reply to Richard Newman [:rnewman] from comment #1) > Ehsan: is this a quit very soon after starting the browser, or a long-lived > session? Hmm, this is from my debug builds, and I usually use them for a few minutes for testing something at most. > What build? My latest build where I see this is from m-c's tip. > Could you crank datareporting.healthreport.logging.console{Level,Enabled} > and grab more console output? What values do you want me to set for them?

Also note that this is very easy to reproduce. Just run a debug build a few times!

gdb dump follows: Assertion failure: !connections[i]->ConnectionReady(), at /Users/ehsanakhgari/moz/mozilla-central/storage/src/mozStorageService.cpp:828 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 mozilla::storage::Service::Observe (this=0x10f44e300, aTopic=0x10520e401 "xpcom-shutdown-threads") at /Users/ehsanakhgari/moz/mozilla-central/storage/src/mozStorageService.cpp:828 828 MOZ_ASSERT(!connections[i]->ConnectionReady()); (gdb) bt #0 mozilla::storage::Service::Observe (this=0x10f44e300, aTopic=0x10520e401 "xpcom-shutdown-threads") at /Users/ehsanakhgari/moz/mozilla-central/storage/src/mozStorageService.cpp:828 #1 0x000000010317a50f in non-virtual thunk to mozilla::storage::Service::Observe(nsISupports*, char const*, unsigned short const*) () at /Users/ehsanakhgari/moz/mozilla-central/storage/src/mozStorageService.cpp:833 #2 0x0000000103ba0759 in nsObserverList::NotifyObservers (this=0x11bb4c0f8, aSubject=0x0, aTopic=0x10520e401 "xpcom-shutdown-threads", someData=0x0) at /Users/ehsanakhgari/moz/mozilla-central/xpcom/ds/nsObserverList.cpp:99 #3 0x0000000103ba2cb4 in nsObserverService::NotifyObservers (this=0x10c64e830, aSubject=0x0, aTopic=0x10520e401 "xpcom-shutdown-threads", someData=0x0) at /Users/ehsanakhgari/moz/mozilla-central/xpcom/ds/nsObserverService.cpp:161 #4 0x0000000103b7a462 in mozilla::ShutdownXPCOM (servMgr=0x10053d698) at /Users/ehsanakhgari/moz/mozilla-central/xpcom/build/nsXPComInit.cpp:560 #5 0x0000000103b7a1b5 in NS_ShutdownXPCOM_P (servMgr=0x10053d698) at /Users/ehsanakhgari/moz/mozilla-central/xpcom/build/nsXPComInit.cpp:513 #6 0x00000001013d36f0 in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0x10050e2b8) at /Users/ehsanakhgari/moz/mozilla-central/toolkit/xre/nsAppRunner.cpp:1124 #7 0x00000001013d3605 in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0x10050e2b8) at /Users/ehsanakhgari/moz/mozilla-central/toolkit/xre/nsAppRunner.cpp:1105 #8 0x00000001013dcb6a in XREMain::XRE_main (this=0x7fff5fbfea90, argc=5, argv=0x7fff5fbff348, aAppData=0x7fff5fbfecc8) at /Users/ehsanakhgari/moz/mozilla-central/toolkit/xre/nsAppRunner.cpp:3915 #9 0x00000001013dcf5d in XRE_main (argc=5, argv=0x7fff5fbff348, aAppData=0x7fff5fbfecc8, aFlags=0) at /Users/ehsanakhgari/moz/mozilla-central/toolkit/xre/nsAppRunner.cpp:4093 #10 0x000000010000207e in do_main (argc=5, argv=0x7fff5fbff348, xreDirectory=0x100527500) at /Users/ehsanakhgari/moz/mozilla-central/browser/app/nsBrowserApp.cpp:195 #11 0x000000010000169d in main (argc=5, argv=0x7fff5fbff348) at /Users/ehsanakhgari/moz/mozilla-central/browser/app/nsBrowserApp.cpp:388 (gdb) p *connections[i].mRawPtr $2 = (mozilla::storage::Connection) { <mozIStorageConnection> = { <nsISupports> = { _vptr$nsISupports = 0x106709070 }, <No data fields>}, <nsIInterfaceRequestor> = { <nsISupports> = { _vptr$nsISupports = 0x106709190 }, <No data fields>}, members of mozilla::storage::Connection: mRefCnt = { mValue = 6 }, _mOwningThread = { mThread = 0x100563070 }, sharedAsyncExecutionMutex = { <mozilla::BlockingResourceBase> = { mChainPrev = 0x0, mDDEntry = 0x1137f2fe0 }, members of mozilla::Mutex: mLock = 0x1120f5740 }, sharedDBMutex = { <mozilla::BlockingResourceBase> = { mChainPrev = 0x0, mDDEntry = 0x113819380 }, members of mozilla::storage::SQLiteMutex: mMutex = 0x1137eb440 }, threadOpenedOn = { mRawPtr = 0x10053ab70 }, mDBConn = 0x11d917c00, mFileURL = { mRawPtr = 0x0 }, mDatabaseFile = { mRawPtr = 0x1120f5680 }, mAsyncExecutionThread = { mRawPtr = 0x11e990e60 }, mAsyncExecutionThreadShuttingDown = false, mTransactionInProgress = false, mFunctions = { <nsBaseHashtable<nsCStringHashKey, mozilla::storage::Connection::FunctionInfo, mozilla::storage::Connection::FunctionInfo>> = { <nsTHashtable<nsBaseHashtableET<nsCStringHashKey, mozilla::storage::Connection::FunctionInfo> >> = { mTable = { ops = 0x10683d9b0, data = 0x0, hashShift = 28, maxAlphaFrac = 192 '?', minAlphaFrac = 64 '@', entrySize = 40, entryCount = 0, removedCount = 0, generation = 0, entryStore = 0x11bd31c00 "" } }, <No data fields>}, <No data fields>}, mProgressHandler = { mRawPtr = 0x0 }, mFlags = 262150, mStorageService = { mRawPtr = 0x10f44e300 } }

(In reply to :Ehsan Akhgari from comment #2) > What values do you want me to set for them? Set *Level to "Trace" (leading cap) and restart. Make sure *Enabled is true.

Waiting on FHR logs from Ehsan.

Hmm, so apparently the logs go to the error console which makes it impossible for me to grab them when the crash happens...

OK, here's a log: https://gist.github.com/4532814

Like bug 830448, this log shows no sign of FHR receiving the "quit-application" shutdown notification, which is required for FHR to shut down. So, the question is: why doesn't FHR see this notification? Is the notification not being sent or is FHR not receiving it?

I'm reasonably confident the fix in bug 828149 addressed this.