The call in nsComponentManagerImpl::gComponentManager->FreeServices(); in ShutdownXPCOM is past the point where we would like to exit(0), but it can write to disk: #1 0x017b1293 in wrap_write_UNIX2003 (fd=9, buf=0xbfffea58, count=260) at /Users/espindola/mozilla-central/xpcom/build/mozPoisonWrite.cpp:99 #2 0x08add2b1 in flush_meta (hashp=0x4a98490) at ../../../dbm/src/hash.c:627 #3 0x08adc636 in hdestroy (hashp=0x4a98490) at ../../../dbm/src/hash.c:473 #4 0x08adbb62 in hash_close (dbp=0x4a981b0) at ../../../dbm/src/hash.c:294 #5 0x08aa80f4 in dbs_close (dbs=0x4a98360) at dbmshim.c:526 #6 0x08abffdd in certdb_Close (db=0x4a98360) at pcertdb.c:352 #7 0x08abfef5 in nsslowcert_ClosePermCertDB (handle=0x4a97480) at pcertdb.c:4479 #8 0x08ab8dd4 in lg_Close (sdb=0x4a983d0) at lginit.c:499 #9 0x07844bea in sftkdb_CloseDB (handle=0x4a989b0) at sftkdb.c:1496 #10 0x07845d1c in sftk_freeDB (handle=0x4a989b0) at sftkdb.c:2430 #11 0x07819225 in sftk_DBShutdown (slot=0x4a97b70) at pkcs11.c:2538 #12 0x0781864a in SFTK_ShutdownSlot (slot=0x4a97b70) at pkcs11.c:2570 #13 0x07818cf0 in SFTK_DestroySlotData (slot=0x4a97b70) at pkcs11.c:2582 #14 0x07819c71 in nscFreeAllSlots (moduleIndex=0) at pkcs11.c:2714 #15 0x07819f5c in nsc_CommonFinalize (pReserved=0x0, isFIPS=0) at pkcs11.c:2901 #16 0x0781a0a7 in NSC_Finalize (pReserved=0x0) at pkcs11.c:2992 #17 0x0461da44 in SECMOD_UnloadModule (mod=0x512c610) at pk11load.c:586 #18 0x046496cc in SECMOD_SlotDestroyModule (module=0x512c610, fromSlot=1) at pk11util.c:884 #19 0x04642dde in PK11_DestroySlot (slot=0x512ee00) at pk11slot.c:452 #20 0x046423f3 in PK11_FreeSlot (slot=0x512ee00) at pk11slot.c:465 #21 0x04647e77 in SECMOD_DestroyModule (module=0x512c610) at pk11util.c:855 #22 0x046489f2 in SECMOD_DestroyModuleListElement (element=0x4a97390) at pk11util.c:901 #23 0x04647eba in SECMOD_DestroyModuleList (list=0x4a97390) at pk11util.c:917 #24 0x04647be4 in SECMOD_Shutdown () at pk11util.c:99 #25 0x045dd83f in nss_Shutdown () at nssinit.c:1105 #26 0x045ddab5 in NSS_Shutdown () at nssinit.c:1156 #27 0x012941b6 in nsNSSComponent::ShutdownNSS (this=0x4a92ff0) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsNSSComponent.cpp:1969 #28 0x01293dbf in ~nsNSSComponent (this=0x4a92ff0) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsNSSComponent.cpp:439 #29 0x01293c31 in ~nsNSSComponent [inlined] () at /Users/espindola/mozilla-central/security/manager/ssl/src/nsNSSComponent.h:416 #30 0x01293c31 in ~nsNSSComponent (this=0x4a92ff0) at mozalloc.h:416 #31 0x0129acb0 in non-virtual thunk to nsNSSComponent::Release() () at /Users/espindola/mozilla-central/security/manager/ssl/src/nsNSSComponent.cpp:2087 #32 0x017a2b3b in nsCOMPtr_base::assign_with_AddRef (this=<value temporarily unavailable, due to optimizations>, rawPtr=<value temporarily unavailable, due to optimizations>) at nsCOMPtr.h:469 #33 0x017fec15 in nsCOMPtr<nsISupports>::operator= () at /Users/espindola/mozilla-central/obj-x86_64-apple-darwin11.3.0/dist/include/nsCOMPtr.h:1088 #34 0x017fec15 in FreeFactoryEntries (aCID=@0x7116614, aEntry=<value temporarily unavailable, due to optimizations>, arg=0x0) at /Users/espindola/mozilla-central/xpcom/components/nsComponentManager.cpp:1088 #35 0x0180122b in nsBaseHashtable<nsIDHashKey, nsFactoryEntry*, nsFactoryEntry*>::s_EnumReadStub (table=0x4e68200, hdr=0x7116610, number=130, arg=0xbffff138) at nsBaseHashtable.h:396 #36 0x017aa674 in PL_DHashTableEnumerate (table=0x4e68200) at pldhash.cpp:750 #37 0x017febc0 in nsBaseHashtable<nsIDHashKey, nsFactoryEntry*, nsFactoryEntry*>::EnumerateRead () at /Users/espindola/mozilla-central/obj-x86_64-apple-darwin11.3.0/dist/include/nsBaseHashtable.h:204 #38 0x017febc0 in nsComponentManagerImpl::FreeServices (this=<value temporarily unavailable, due to optimizations>) at nsBaseHashtable.h:1100 #39 0x017b07f9 in mozilla::ShutdownXPCOM (servMgr=<value temporarily unavailable, due to optimizations>) at /Users/espindola/mozilla-central/xpcom/build/nsXPComInit.cpp:672

During XPCOM shutdown, we should not be writing to the certdb because the certdb is in the profile directory, and we should not access the profile directory after profile-before-change. Ideally, we would be able to close the cert db during profile-before-change, but then keep the rest of NSS available until xpcom-shutdown. The bigger question is whether NSS really should be writing during SECMOD_Shutdown at all. Even if we moved the shutting down of the certdb to profile-before-change, this has a negative effect on shutdown performance, which means it has a negative effect on restart performance, which we are trying to optimize for our silent update feature. Perhaps, this is one of the things that can be fixed by using the cert9 db format? If so, that is good. But, we may need to find a solution before then.

Brian, We need to fix this in the near term for bug 662444. Waiting for new file format does not sound like a great option. I'm ok with regressing performance in the near term since once we fix 662444, it will be much easier to drastically improve shutdown speed.

> Ideally, we would be able to close the cert db during profile-before-change, > but then keep the rest of NSS available until xpcom-shutdown. What needs nss during xpcom-shutodwn? My idea for a "short" term fix is to move the nss shutdown (and anything that depends on it) to profile-before change.

I propose to discuss possible solutions in the weekly NSS conf call.

(In reply to Kai Engert (:kaie) from comment #4) > I propose to discuss possible solutions in the weekly NSS conf call. The idea for the short term fix is to just shutdown nss earlier. That is a change in how firefox uses nss, not in nss itself.

The only way to avoid this write is to move to the new database code, or change when you close NSS (which means making sure all your NSS handles are have been flushed. What you are seeing is a nasty behavior for the old database code. I think the latter is tricky. You see the stack trace here is shutting down NSS after some XP_COM resource, presumably holding an NSS handle, has been shutdown. Changeing the actual NSS_Shutdown() call won't affect the fact that the database won't actually be closed until that handle is freed by mozilla. Probably the simplest thing is to simply go to the new database format in the same profile location. The original thought was that we would converge where the various NSS database roundevous, but the new database code is now a half - a - decade old and we are still doing things with DBM. At this point we should just get on with it. bob

We currently call NSS_Shutdown when we receive profile-before-change. We also changed things so NSS can be initialized once and only once, so I don't think this is relevant any longer (unless someone can reproduce the issue).