Closed Bug 752642 Opened 13 years ago Closed 9 years ago

Disk writes during xpcom-shutdown-loaders caused by nsKeyObject destructor

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1230377

People

(Reporter: espindola, Unassigned)

References

Details

Found by poisoning write: #0 0x00000001018f1c1b in AbortOnBadWrite (fd=10, count=16384) at /Users/espindola/mozilla-central/xpcom/build/mozPoisonWrite.cpp:92 #1 0x00000001018f1d03 in wrap_write (fd=10, buf=0x10831ba00, count=16384) at /Users/espindola/mozilla-central/xpcom/build/mozPoisonWrite.cpp:97 #2 0x000000011d0a019f in __put_page (hashp=0x11cf08630, p=0x10831ba00 "\002", bucket=0, is_bucket=4, is_bitmap=0) at ../../../dbm/src/h_page.c:866 #3 0x000000011d0a4b26 in __buf_free (hashp=0x11cf08630, do_free=1, to_disk=1) at ../../../dbm/src/hash_buf.c:375 #4 0x000000011d0a1c3c in hdestroy (hashp=0x11cf08630) at ../../../dbm/src/hash.c:464 #5 0x000000011d0a16f9 in hash_close (dbp=0x11cf08200) at ../../../dbm/src/hash.c:294 #6 0x000000011d07b535 in dbs_close (dbs=0x11cf08590) at dbmshim.c:526 #7 0x000000011d08b366 in certdb_Close (db=0x11cf08590) at pcertdb.c:352 #8 0x000000011d092c0a in nsslowcert_ClosePermCertDB (handle=0x11cf082c0) at pcertdb.c:4479 #9 0x000000011d087af8 in lg_Close (sdb=0x11cf08940) at lginit.c:499 #10 0x000000011d034993 in sftkdb_CloseDB (handle=0x11cf08db0) at sftkdb.c:1496 #11 0x000000011d03626c in sftk_freeDB (handle=0x11cf08db0) at sftkdb.c:2430 #12 0x000000011d012fe3 in sftk_DBShutdown (slot=0x11cf07740) at pkcs11.c:2538 #13 0x000000011d013096 in SFTK_ShutdownSlot (slot=0x11cf07740) at pkcs11.c:2570 #14 0x000000011d0130b2 in SFTK_DestroySlotData (slot=0x11cf07740) at pkcs11.c:2582 #15 0x000000011d0136b5 in nscFreeAllSlots (moduleIndex=0) at pkcs11.c:2714 #16 0x000000011d013b30 in nsc_CommonFinalize (pReserved=0x0, isFIPS=0) at pkcs11.c:2901 #17 0x000000011d013d1e in NSC_Finalize (pReserved=0x0) at pkcs11.c:2992 #18 0x0000000107229b91 in SECMOD_UnloadModule (mod=0x11cf03200) at pk11load.c:586 #19 0x0000000107248e71 in SECMOD_SlotDestroyModule (module=0x11cf03200, fromSlot=1) at pk11util.c:884 #20 0x0000000107243e99 in PK11_DestroySlot (slot=0x11cf09de0) at pk11slot.c:452 #21 0x0000000107243edf in PK11_FreeSlot (slot=0x11cf09de0) at pk11slot.c:465 #22 0x000000010723e89f in PK11_FreeSymKey (symKey=0x11cf14af0) at pk11skey.c:265 #23 0x000000010138ce69 in nsKeyObject::CleanUp (this=0x11cf14910) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsKeyModule.cpp:60 #24 0x000000010138cf95 in nsKeyObject::~nsKeyObject (this=0x11cf14910) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsKeyModule.cpp:52 #25 0x000000010138d226 in nsKeyObject::Release (this=0x11cf14910) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsKeyModule.cpp:42 #26 0x00000001010b9efd in DoDeferredRelease<nsISupports*> (array=@0x10764ac38) at /Users/espindola/mozilla-central/js/xpconnect/src/XPCJSRuntime.cpp:634 #27 0x00000001010bf4fb in XPCJSRuntime::GCCallback (rt=0x108f1d000, status=JSGC_END) at /Users/espindola/mozilla-central/js/xpconnect/src/XPCJSRuntime.cpp:685 #28 0x00000001020fc65f in Collect () at /Users/espindola/mozilla-central/js/src/jsgc.cpp:3698 #29 0x00000001020fc809 in js::GC (rt=0x108f1d000, gckind=js::GC_NORMAL, reason=js::gcreason::DESTROY_CONTEXT) at /Users/espindola/mozilla-central/js/src/jsgc.cpp:3713 #30 0x00000001020c0170 in js::DestroyContext (cx=0x10884b690, mode=js::DCM_FORCE_GC) at /Users/espindola/mozilla-central/js/src/jscntxt.cpp:277 #31 0x0000000102073f11 in JS_DestroyContext (cx=0x10884b690) at /Users/espindola/mozilla-central/js/src/jsapi.cpp:1149 #32 0x00000001011c5feb in mozJSComponentLoader::UnloadModules (this=0x10884b250) at /Users/espindola/mozilla-central/js/xpconnect/loader/mozJSComponentLoader.cpp:993 #33 0x00000001011c605b in mozJSComponentLoader::Observe (this=0x10884b250, subject=0x0, topic=0x1025b3406 "xpcom-shutdown-loaders", data=0x0) at /Users/espindola/mozilla-central/js/xpconnect/loader/mozJSComponentLoader.cpp:1312 #34 0x00000001018ee0c2 in mozilla::ShutdownXPCOM (servMgr=0x0) at /Users/espindola/mozilla-central/xpcom/build/nsXPComInit.cpp:735 #35 0x00000001018ee39e in NS_ShutdownXPCOM_P (servMgr=0x0) at /Users/espindola/mozilla-central/xpcom/build/nsXPComInit.cpp:570 #36 0x0000000100043100 in NS_ShutdownXPCOM (svcMgr=0x0) at /Users/espindola/mozilla-central/xpcom/stub/nsXPComStub.cpp:167 #37 0x0000000100006d81 in main (argc=20, argv=0x7fff5fbfe9f0, envp=0x7fff5fbfea98) at /Users/espindola/mozilla-central/js/xpconnect/shell/xpcshell.cpp:2036
At least in this particular case it seems like it is possible to just drop the reference one gc cycle earlier: https://tbpl.mozilla.org/?tree=Try&rev=ec352a89c064 It would not move it as far back as profile-before-change, but would move it in the right direction and would let us poison writes a bit earlier.
(In reply to Rafael Ávila de Espíndola (:espindola) from comment #1) > At least in this particular case it seems like it is possible to just drop > the reference one gc cycle earlier: > > https://tbpl.mozilla.org/?tree=Try&rev=ec352a89c064 > > It would not move it as far back as profile-before-change, but would move it > in the right direction and would let us poison writes a bit earlie Looking a bit more I now think this is too error prone to work in practice :-( We can cover all the references that our tests find, but there can always be another one keeping a nsKeyObject alive.
> Looking a bit more I now think this is too error prone to work in practice > :-( > We can cover all the references that our tests find, but there can always be > another one keeping a nsKeyObject alive. I looked at how chromium handles this. The answer looks to be by note exposing anything to JS that would require it to call PK11_FreeSlot during a GC. While I would love to do the same for firefox (basically by deleting nsIKeyObject), it looks like that would mean rewriting the security manager and sync in c++, which is probably also not in the timeline we want :-( The two ideas I have in mind right now are * Add a NSS_FreezeDB api to NSS that causes it to write any pending writes to disk and error on any new attempt to change the db. Not sure how hard this is on the NSS side. We would still need to check that everything from the firefox side handles it OK, which is not trivial. * A Firefox only fix is to make nsIKeyObject a manually managed resource by adding a Destroy method to it and requiring clients to call it. We would then have to audit our code, but this would be similar to what we did for Close being called in mozIStorageConnection.
nsKeyObject does NOT extend nsNSSShutdownObject, so of course it isn't cleaning up its reference to its underlying NSS objects when it is supposed to. This is a problem that affects not just nsKeyObject. The stack trace is from a GC operation on a JS object that has a reference to an nsKeyObject; the destructor ~nsKeyObject() calls PK11_FreeSymKey() which decreases the refcount of the key object and causes the database to be closed. In particular, notice that this is NOT from the destructor of nsNSSComponent or its xpcom-shutdown observer. One option is to have every class that uses NSS objects in Gecko correctly implement nsNSSShutdownObject, and then verify that all of the users of those classes gracefully handle the errors/exceptions that would be returned from calling methods on instances of those classes after NSS has been shut down. That seems like a lot of simple but tedious work. Another option is to simply never call NSS_Shutdown, so that once NSS has been started, it is always available. This, in turn, would impose upon Gecko the requirement that, once a user profile is available, it is never taken away. This means any "don't call NSS_Shutdown" solution should be done at the same time we start _exit(0)ing. In the long term, there are several benefits to the "don't call NSS_Shutdown" solution: 1. Avoiding NSS_Shutdown *directly* results in less work at shutdown, making shutdown faster. 2. We do some work, such as joining background threads (e.g. the certificate verification threads) to the main thread, purely to prepare for calling NSS_Shutdown; we would eventually not need to do this any more, meaning more savings. These savings could be significant. 3. Avoiding NSS_Shutdown means we never have to care about "what if NSS isn't available" except at startup. This makes verifying the correctness of the system much easier. 4. Avoiding NSS_Shutdown means we can get rid of the need for nsNSSShutdownObject, which makes using NSS in Gecko easier and less error-prone. There are also some significant risks regarding what happens if the keydb or the certdb becomes corrupt due to a failure to write the metadata that is normally written during shutdown: 1. Do we fail to start up? 2. Does SSL stop working? 3. Do other crypto operations stop working? 4. Does the user lose his private keys and/or personal certificates? 5. Does the user lose his custom certificate trust settings that are stored in the certificate database? Since we also fail to call NSS_Shutdown when we crash, we already have exposure to these risks. However, purposefully avoiding NSS_Shutdown means that we have a greater exposure to them. We should avoid adding additional exposure to corruption if possible. The fastest way to ensure that, AFAICT, is to ensure that whenever we write to the databases, we immediately flush those writes so that there are no dirty buffers in memory. I noticed that (almost?) every write to the databases (e.g. db->put) is followed by a db->sync, which AFAICT is supposed to flush those changes so that there should be nothing to write out afterward. But, either some places aren't calling db->sync or things are not working as intended there. espindola investigated exactly WHAT we are writing to disk every time we shut down the keydb. It turns out, the test that causes this write is a Firefox Sync test. I looked at the Firefox Sync code. It uses nsIKeyObjectFactory.keyFromString to create HMAC keys. In keyFromString: PK11SymKey* symKey = PK11_ImportSymKey(slot, cipherMech, PK11_OriginUnwrap, cipherOperation, &keyItem, nsnull); I believe that this should be creating only a session key, and not a token key, so this shouldn't be causing any writes to the keydb at all, but it seems that it is. Really, this is a separate issue, but it is related in that we want to avoid writing to these databases as much as possible to limit corruption and for performance reasons anyway.
Blocks: 662444
Component: XPCOM → Security: PSM
QA Contact: xpcom → psm
Summary: Disk writes during xpcom-shutdown-loaders → Disk writes during xpcom-shutdown-loaders caused by nsKeyObject destructor
I modified the write poisoning patch to only abort if the contents would be modified by the write and the tests now pass: https://tbpl.mozilla.org/?tree=Try&rev=8af5324dbc9d Since the write in question is protected by if (to_disk && (bp->flags & BUF_MOD)... it looks like BUF_MOD is not being handled correctly. I will try to track that down tomorrow.
It does look like the problem is BUF_MOD not being cleared when data is sync to disk. I tracked the db that causes the late write to disk. We can __buf_free on it twice. The first time is when we create the db and correctly sync it to disk: #0 __buf_free (hashp=0x10b104840, do_free=0, to_disk=1) at ../../../dbm/src/hash_buf.c:368 #1 0x000000010e2ba1c6 in hash_sync (dbp=0x10b1008e0, flags=0) at ../../../dbm/src/hash.c:588 #2 0x000000010e2895f8 in dbs_sync (dbs=0x10b1047a0, flags=0) at dbmshim.c:477 #3 0x000000010e2a3f75 in certdb_Sync (db=0x10b1047a0, flags=0) at pcertdb.c:299 #4 0x000000010e2a3e33 in WriteDBEntry (handle=0x10856b010, entry=0x10b802420, dbkey=0x7fff5fbdf7a8, dbentry=0x7fff5fbdf7c0) at pcertdb.c:595 #5 0x000000010e2a5a87 in WriteDBVersionEntry (handle=0x10856b010, entry=0x10b802420) at pcertdb.c:2960 #6 0x000000010e2a56de in openNewCertDB (appName=0x0, prefix=0x108569800 "", certdbname=0x108573310 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile/cert8.db", handle=0x10856b010, namecb=0x10e299890 <lg_certdb_name_cb>, cbarg=0x10856afa0) at pcertdb.c:4052 #7 0x000000010e2a00c9 in nsslowcert_OpenPermCertDB (handle=0x10856b010, readOnly=0, appName=0x0, prefix=0x108569800 "", namecb=0x10e299890 <lg_certdb_name_cb>, cbarg=0x10856afa0) at pcertdb.c:4150 #8 0x000000010e29fef1 in nsslowcert_OpenCertDB (handle=0x10856b010, readOnly=0, appName=0x0, prefix=0x108569800 "", namecb=0x10e299890 <lg_certdb_name_cb>, cbarg=0x10856afa0, openVolatile=0) at pcertdb.c:4628 #9 0x000000010e2995d3 in lg_OpenCertDB (configdir=0x108572600 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile", prefix=0x108569800 "", readOnly=0, certdbPtr=0x7fff5fbdf9b8) at lginit.c:404 #10 0x000000010e29933f in legacy_Open (configdir=0x108572600 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile", certPrefix=0x108569800 "", keyPrefix=0x10856e860 "", certVersion=8, keyVersion=3, flags=4, certDB=0x7fff5fbdfc38, keyDB=0x7fff5fbdfc40) at lginit.c:645 #11 0x000000010e20d0f5 in sftkdbCall_open (dir=0x108572600 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile", certPrefix=0x108569800 "", keyPrefix=0x10856e860 "", certVersion=8, keyVersion=3, flags=4, isFIPS=0, certDB=0x7fff5fbdfc38, keyDB=0x7fff5fbdfc40) at lgglue.c:362 #12 0x000000010e240708 in sftk_DBInit (configdir=0x108572600 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile", certPrefix=0x108569800 "", keyPrefix=0x10856e860 "", updatedir=0x108572330 "", updCertPrefix=0x0, updKeyPrefix=0x0, updateID=0x108572340 "", readOnly=0, noCertDB=0, noKeyDB=0, forceOpen=0, isFIPS=0, certDB=0x7fff5fbdfde0, keyDB=0x7fff5fbdfdd8) at sftkdb.c:2635 #13 0x000000010e21520c in SFTK_SlotReInit (slot=0x10856a620, configdir=0x108572600 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile", updatedir=0x108572330 "", updateID=0x108572340 "", params=0x10856af28, moduleIndex=0) at pkcs11.c:2325 #14 0x000000010e2159a8 in SFTK_SlotInit (configdir=0x108572600 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile", updatedir=0x108572330 "", updateID=0x108572340 "", params=0x10856af28, moduleIndex=0) at pkcs11.c:2437 #15 0x000000010e2168aa in nsc_CommonInitialize (pReserved=0x7fff5fbdffe8, isFIPS=0) at pkcs11.c:2825 #16 0x000000010e216c67 in NSC_Initialize (pReserved=0x7fff5fbdffe8) at pkcs11.c:2887 #17 0x00000001080b2c5c in secmod_ModuleInit (mod=0x10b101000, reload=0x7fff5fbe0168, alreadyLoaded=0x7fff5fbe0090) at pk11load.c:252 #18 0x00000001080b3687 in secmod_LoadPKCS11Module (mod=0x10b101000, oldModule=0x7fff5fbe0168) at pk11load.c:488 #19 0x00000001080c7d13 in SECMOD_LoadModule (modulespec=0x10b100ad0 "library= name=\"NSS Internal PKCS #11 Module\" parameters=\"configdir='/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile' certPrefix='' keyPrefix='' secmod='secmod.db' flags=optim"..., parent=0x10dd96510, recurse=1) at pk11pars.c:1121 #20 0x00000001080c7e26 in SECMOD_LoadModule (modulespec=0x10dd94e00 "name=\"PSM Internal Crypto Services\" parameters=\"configdir='/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile' certPrefix='' keyPrefix='' secmod='secmod.db' flags=optimizeSpace "..., parent=0x0, recurse=1) at pk11pars.c:1156 #21 0x000000010807a08d in nss_InitModules (configdir=0x10dd94118 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile", certPrefix=0x102fffa98 "", keyPrefix=0x102fffa98 "", secmodName=0x10307745a "secmod.db", updateDir=0x1081d072c "", updCertPrefix=0x1081d072c "", updKeyPrefix=0x1081d072c "", updateID=0x1081d072c "", updateName=0x1081d072c "", configName=0x10dd93f30 "PSM Internal Crypto Services", configStrings=0x10dd943c0 " manufacturerID='Mozilla.org' libraryDescription='PSM Internal Crypto Services' cryptoTokenDescription='Generic Crypto Services' dbTokenDescription='Software Security Device' cryptoSlotDescription='PS"..., pwRequired=0, readOnly=0, noCertDB=0, noModDB=0, forceOpen=0, optimizeSpace=1, isContextInit=0) at nssinit.c:469 #22 0x000000010807821d in nss_Init (configdir=0x10dd94118 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile", certPrefix=0x102fffa98 "", keyPrefix=0x102fffa98 "", secmodName=0x10307745a "secmod.db", updateDir=0x1081d072c "", updCertPrefix=0x1081d072c "", updKeyPrefix=0x1081d072c "", updateID=0x1081d072c "", updateName=0x1081d072c "", initContextPtr=0x0, initParams=0x0, readOnly=0, noCertDB=0, noModDB=0, forceOpen=0, noRootInit=1, optimizeSpace=1, noSingleThreadedModules=0, allowAlreadyInitializedModules=0, dontFinalizeModules=0) at nssinit.c:671 #23 0x000000010807887b in NSS_Initialize (configdir=0x10dd94118 "/var/folders/m4/v03wy25x5ng881g2x9s22w_00000gn/T/xpcshell/xpcshellprofile", certPrefix=0x102fffa98 "", keyPrefix=0x102fffa98 "", secmodName=0x10307745a "secmod.db", flags=48) at nssinit.c:840 #24 0x0000000101963574 in nsNSSComponent::InitializeNSS (this=0x10dd92e00, showWarningBox=true) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsNSSComponent.cpp:1786 #25 0x0000000101964506 in nsNSSComponent::Init (this=0x10dd92e00) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsNSSComponent.cpp:2024 #26 0x0000000101983f6e in nsNSSComponentConstructor (aOuter=0x0, aIID=@0x1088ad1f8, aResult=0x7fff5fbe0d10) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsNSSModule.cpp:211 #27 0x000000010207325e in mozilla::GenericFactory::CreateInstance (this=0x10dd92de0, aOuter=0x0, aIID=@0x1088ad1f8, aResult=0x7fff5fbe0d10) at GenericFactory.cpp:48 #28 0x00000001020ec8fd in nsComponentManagerImpl::CreateInstance (this=0x10852ac90, aClass=@0x10dd888e8, aDelegate=0x0, aIID=@0x1088ad1f8, aResult=0x7fff5fbe0d10) at /Users/espindola/mozilla-central/xpcom/components/nsComponentManager.cpp:977 #29 0x00000001020e897c in nsComponentManagerImpl::GetService (this=0x10852ac90, aClass=@0x10dd888e8, aIID=@0x1088ad1f8, result=0x7fff5fbe0ea8) at /Users/espindola/mozilla-central/xpcom/components/nsComponentManager.cpp:1270 #30 0x00000001020ece2a in non-virtual thunk to nsComponentManagerImpl::GetService(nsID const&, nsID const&, void**) () at /Users/espindola/mozilla-central/xpcom/components/nsComponentManager.cpp:1089 #31 0x000000010161f90e in nsJSCID::GetService (this=0x10dd888b0, iidval=@0x7fff5fbe11f0, cx=0x109c74250, optionalArgc=1 '\001', retval=0x7fff5fbe1238) at /Users/espindola/mozilla-central/js/xpconnect/src/XPCJSID.cpp:818 The BUF_MOD ends up being set (in __addel I think) and is never cleared. We then write the same data again on shutdown: #0 __buf_free (hashp=0x10b104840, do_free=1, to_disk=1) at ../../../dbm/src/hash_buf.c:368 #1 0x000000010e2ba23b in hdestroy (hashp=0x10b104840) at ../../../dbm/src/hash.c:464 #2 0x000000010e2b9855 in hash_close (dbp=0x10b1008e0) at ../../../dbm/src/hash.c:294 #3 0x000000010e289232 in dbs_close (dbs=0x10b1047a0) at dbmshim.c:526 #4 0x000000010e29f8f9 in certdb_Close (db=0x10b1047a0) at pcertdb.c:352 #5 0x000000010e29f837 in nsslowcert_ClosePermCertDB (handle=0x10856b010) at pcertdb.c:4479 #6 0x000000010e298e5f in lg_Close (sdb=0x10b104af0) at lginit.c:499 #7 0x000000010e23f0a0 in sftkdb_CloseDB (handle=0x10b104f20) at sftkdb.c:1496 #8 0x000000010e2401bc in sftk_freeDB (handle=0x10b104f20) at sftkdb.c:2430 #9 0x000000010e216260 in sftk_DBShutdown (slot=0x10856a620) at pkcs11.c:2538 #10 0x000000010e215650 in SFTK_ShutdownSlot (slot=0x10856a620) at pkcs11.c:2570 #11 0x000000010e215cf5 in SFTK_DestroySlotData (slot=0x10856a620) at pkcs11.c:2582 #12 0x000000010e216bd6 in nscFreeAllSlots (moduleIndex=0) at pkcs11.c:2714 #13 0x000000010e216e43 in nsc_CommonFinalize (pReserved=0x0, isFIPS=0) at pkcs11.c:2901 #14 0x000000010e216f5c in NSC_Finalize (pReserved=0x0) at pkcs11.c:2992 #15 0x00000001080b3b9c in SECMOD_UnloadModule (mod=0x10b101000) at pk11load.c:586 #16 0x00000001080dd976 in SECMOD_SlotDestroyModule (module=0x10b101000, fromSlot=1) at pk11util.c:884 #17 0x00000001080d74c2 in PK11_DestroySlot (slot=0x10b105e90) at pk11slot.c:452 #18 0x00000001080d6a3f in PK11_FreeSlot (slot=0x10b105e90) at pk11slot.c:465 #19 0x00000001080d01e6 in PK11_FreeSymKey (symKey=0x10857bd80) at pk11skey.c:265 #20 0x00000001019d6183 in nsKeyObject::CleanUp (this=0x10857baf0) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsKeyModule.cpp:60 #21 0x00000001019d6125 in nsKeyObject::~nsKeyObject (this=0x10857baf0) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsKeyModule.cpp:52 #22 0x00000001019d5fc5 in nsKeyObject::~nsKeyObject (this=0x10857baf0) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsKeyModule.cpp:51 #23 0x00000001019d5f6a in nsKeyObject::Release (this=0x10857baf0) at /Users/espindola/mozilla-central/security/manager/ssl/src/nsKeyModule.cpp:42 #24 0x000000010162301f in DoDeferredRelease (array=@0x109c24228) at /Users/espindola/mozilla-central/js/xpconnect/src/XPCJSRuntime.cpp:623 #25 0x0000000101622f24 in XPCJSRuntime::GCCallback (rt=0x109f83000, status=JSGC_END) at /Users/espindola/mozilla-central/js/xpconnect/src/XPCJSRuntime.cpp:661 #26 0x0000000102a7eb81 in Collect (rt=0x109f83000, incremental=false, budget=0, gckind=js::GC_NORMAL, reason=js::gcreason::DESTROY_CONTEXT) at /Users/espindola/mozilla-central/js/src/jsgc.cpp:3697 #27 0x0000000102a7cfdc in js::GC (rt=0x109f83000, gckind=js::GC_NORMAL, reason=js::gcreason::DESTROY_CONTEXT) at /Users/espindola/mozilla-central/js/src/jsgc.cpp:3716 #28 0x0000000102a2f508 in js::DestroyContext (cx=0x109c74250, mode=js::DCM_FORCE_GC) at /Users/espindola/mozilla-central/js/src/jscntxt.cpp:310 #29 0x00000001029c2e9a in JS_DestroyContext (cx=0x109c74250) at /Users/espindola/mozilla-central/js/src/jsapi.cpp:1163 #30 0x00000001017815b1 in mozJSComponentLoader::UnloadModules (this=0x109c73830) at /Users/espindola/mozilla-central/js/xpconnect/loader/mozJSComponentLoader.cpp:990 #31 0x000000010178791a in mozJSComponentLoader::Observe (this=0x109c73830, subject=0x0, topic=0x10306138d "xpcom-shutdown-loaders", data=0x0) at /Users/espindola/mozilla-central/js/xpconnect/loader/mozJSComponentLoader.cpp:1309 #32 0x000000010178798f in non-virtual thunk to mozJSComponentLoader::Observe(nsISupports*, char const*, unsigned short const*) () at /Users/espindola/mozilla-central/js/xpconnect/loader/mozJSComponentLoader.cpp:1314 #33 0x0000000102076fd2 in mozilla::ShutdownXPCOM (servMgr=0x0) at /Users/espindola/mozilla-central/xpcom/build/nsXPComInit.cpp:693 #34 0x0000000102076985 in NS_ShutdownXPCOM_P (servMgr=0x0) at /Users/espindola/mozilla-central/xpcom/build/nsXPComInit.cpp:570 #35 0x0000000100052b15 in NS_ShutdownXPCOM (svcMgr=0x0) at /Users/espindola/mozilla-central/xpcom/stub/nsXPComStub.cpp:167 #36 0x0000000100003416 in main (argc=20, argv=0x7fff5fbff1d0, envp=0x7fff5fbff278) at /Users/espindola/mozilla-central/js/xpconnect/shell/xpcshell.cpp:2000
Are you still working on this?
Bug 1230377 made nsKeyObject implement nsNSSShutDownObject, so I believe this shouldn't be an issue anymore. If not, please re-open.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.