see bug 469214 ntdll!DbgBreakPoint xpcom_core!Break(char * aMsg = 0x0012f2a0 "###!!! ASSERTION: Profile change cancellation.: 'Error', file c:/home/mozilla.org/mozilla-central/toolkit/xre/nsXREDirProvider.cpp, line 837")+0x230 xpcom_core!NS_DebugBreak_P+0x2a4 xul!ProfileChangeStatusImpl::ChangeFailed+0x1f pipnss!nsNSSComponent::DoProfileBeforeChange+0xc5 pipnss!nsNSSComponent::Observe+0xf9 xpcom_core!nsObserverList::NotifyObservers+0x65 xpcom_core!nsObserverService::NotifyObservers+0xdf xul!nsXREDirProvider::DoShutdown+0x189 xul!ScopedXPCOMStartup::~ScopedXPCOMStartup+0x5d xul!XRE_main+0x343c firefox!NS_internal_main+0x2b2 firefox!wmain+0x119 firefox!__tmainCRTStartup+0x1a6 firefox!wmainCRTStartup+0xd kernel32!BaseProcessStart+0x23 psm wants to cancel the shutdown because ShutdownNSS failed (no idea why)

nelson: could you possibly suggest why nss is likely to decide to fail to shutdown? the candidates seem to be: nss_ShutdownShutdownList this looks like ssl_ShutdownLocks because of ssl_InitSessionCacheLocks (which seems likely ??) STAN_Shutdown (nssTrustDomain_DestroyCache/nssCertificateStore_Destroy "nss is busy") SECMOD_Shutdown (this looks like "nss is busy")

NSS_Shutdown will return SECFailure with the "busy" error code if any reference to any NSS Slot object is still outstanding at the time that the shutdown is attempted. Any slot reference still outstanding at that time is considered to be leaked. Historically, there have been a lot of problems with applications shutting down and reinitializing NSS (such as when a browser switches profiles), and then trying to use objects that were allocated before the shutdown, objects that hold slot references. Those situations resulted in many false accusations against NSS. Consequently, NSS now refuses to shutdown in the presence of such leaks. NSS itself is extensively tested for slot reference leaks. Most (nearly all) slot reference leaks are due to leaks of slot references (including leaks of objects that contain slot references, such as CERTCertificates) by the application that uses NSS, rather than by NSS itself. Presently there are no known Slot reference leaks in NSS (known to me, that is).

One example of a known slot leak bug in Firefox is bug 456409.

does nss know enough to provide a more useful message for debug builds so this could be chased? it sounds like this should be replaced by an assertion and not returning an error....