350620 - ASSERTION: Profile change cancellation.: 'Error' on shutdown

Status: RESOLVED DUPLICATE of bug 362649

(Core :: Security: PSM, defect)

Description

[Adam Guthrie]

I've been seeing this assertion on shutdown in current trunk builds:

###!!! ASSERTION: Profile change cancellation.: 'Error', file /moz/trunk/mozilla/toolkit/xre/nsXREDirProvider.cpp, line 704

It hasn't always happened. I'd say it started within the last two or three weeks.

I broke in ProfileChangeStatusImpl::ChangeFailed in nsXREDirProvider.cpp and got the following stack:

#0  ProfileChangeStatusImpl::ChangeFailed (this=0x84375f0) at /moz/trunk/mozilla/toolkit/xre/nsXREDirProvider.cpp:704
#1  0xb196a98e in nsNSSComponent::Observe (this=0x8f86bf8, aSubject=0x84375f0, aTopic=0xb7f050d7 "profile-before-change", someData=0xb7f05040) at /moz/trunk/mozilla/security/manager/ssl/src/nsNSSComponent.cpp:1862
#2  0xb7c72347 in nsObserverList::NotifyObservers (this=0x80970a4, aSubject=0x84375f0, aTopic=0xb7f050d7 "profile-before-change", someData=0xb7f05040) at /moz/trunk/mozilla/xpcom/ds/nsObserverList.cpp:128
#3  0xb7c73bd6 in nsObserverService::NotifyObservers (this=0x811e288, aSubject=0x84375f0, aTopic=0xb7f050d7 "profile-before-change", someData=0xb7f05040) at /moz/trunk/mozilla/xpcom/ds/nsObserverService.cpp:174
#4  0xb7ee36dc in nsXREDirProvider::DoShutdown (this=0xbff43528) at /moz/trunk/mozilla/toolkit/xre/nsXREDirProvider.cpp:735
#5  0xb7ed03d7 in ~ScopedXPCOMStartup (this=0xbff43578) at /moz/trunk/mozilla/toolkit/xre/nsAppRunner.cpp:583
#6  0xb7ed774c in XRE_main (argc=3, argv=0xbff43774, aAppData=0x80497e0) at /moz/trunk/mozilla/toolkit/xre/nsAppRunner.cpp:2504
#7  0x08048640 in main (argc=3, argv=0xbff43774) at /moz/trunk/mozilla/browser/app/nsBrowserApp.cpp:61

Comment 1

[Benjamin Smedberg]

Hrm... toolkit doesn't allow profile-change cancellation by design (because it only happens during shutdown after it's impossible to cancel anyway). Why is PSM trying to cancel in this scenario?

Comment 2

[Kai Engert [:KaiE:]]

It is important that all NSS resources are freed before attempting to shut down NSS.

PSM tries hard to track internally whether there are still resources held, not yet freed.

If you run into such a situation, it means we have a leak somewhere.

It would be great if you could find a minimal test session that produces this error and describe what you were attempting, so we are able to track down the leak.

Comment 3

[Kai Engert [:KaiE:]]

cc'ing Bob, we either introduced in recent PSM or recent NSS.

Once we have a reproducable test session, we can track this down by going back to ealier snapshots.

Comment 4

[Adam Guthrie]

Duping to bug 362649, since Boris actually figured out steps to reproduce there.

*** This bug has been marked as a duplicate of 362649 ***