Closed Bug 830145 Opened 7 years ago Closed 7 years ago

Abort during shutdown in a debug build because of outstanding FHR storage connections


(Firefox Health Report Graveyard :: Client: Desktop, defect)

Not set


(Not tracked)



(Reporter: ehsan, Unassigned)



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?
Blocks: 829887
Depends on: 718066
Flags: needinfo?(ehsan)
(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?
Flags: needinfo?(ehsan)
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.
Flags: needinfo?(ehsan)
Hmm, so apparently the logs go to the error console which makes it impossible for me to grab them when the crash happens...
Flags: needinfo?(ehsan)
OK, here's a log:
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.
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 828149
Component: Metrics and Firefox Health Report → Client: Desktop
Product: Mozilla Services → Firefox Health Report
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.