Closed
Bug 380967
Opened 17 years ago
Closed 14 years ago
"ASSERTION: nsNSSComponent relies on profile manager to wait for synchronous shutdown of all network activity" starting firefox on clean profile
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: dbaron, Assigned: KaiE)
References
Details
Attachments
(1 file)
8.34 KB,
text/plain
|
Details |
I see an PSM assertion when starting Firefox on a new profile. Steps to reproduce: cd /path/to/firefox mkdir profiledir ./firefox -no-remote -profile profiledir I get the following assertion, during the shutdown before the extension-manager restart (so it's essentially an execution of Mozilla in which we did relatively little): ###!!! ASSERTION: nsNSSComponent relies on profile manager to wait for synchronous shutdown of all network activity: 'mIsNetworkDown', file /builds/trunk/mozilla/security/manager/ssl/src/ nsNSSComponent::DoProfileBeforeChange(nsISupports*) (/builds/trunk/mozilla/security/manager/ssl/src/nsNSSComponent.cpp:2236) nsNSSComponent::Observe(nsISupports*, char const*, unsigned short const*) (/builds/trunk/mozilla/security/manager/ssl/src/nsNSSComponent.cpp:1878) nsObserverList::NotifyObservers(nsISupports*, char const*, unsigned short const*) (/builds/trunk/mozilla/xpcom/ds/nsObserverList.cpp:127) nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) (/builds/trunk/mozilla/xpcom/ds/nsObserverService.cpp:184) nsXREDirProvider::DoShutdown() (/builds/trunk/mozilla/toolkit/xre/nsXREDirProvider.cpp:765) ~ScopedXPCOMStartup (/builds/trunk/mozilla/toolkit/xre/nsAppRunner.cpp:793) XRE_main (/builds/trunk/mozilla/toolkit/xre/nsAppRunner.cpp:2868) main (/builds/trunk/mozilla/browser/app/nsBrowserApp.cpp:66) __libc_start_main (/usr/src/debug/glibc-2.5-20061008T1257/csu/libc-start.c:262)
Comment 1•17 years ago
|
||
This assertion was added as part of Bug 379582.
Assignee | ||
Comment 2•17 years ago
|
||
CC'ing Boris, as Frank said the assertion was caused by his patch from bug 379582.
Comment 3•17 years ago
|
||
I just moved an existing assertion, sorry. David, what topic is being passed to Observe() in this case? That would at least tell us which call to DoProfileBeforeChange we're looking at. That said, it sounds like we just never saw the PROFILE_CHANGE_NET_TEARDOWN_TOPIC and are now getting a PROFILE_BEFORE_CHANGE_TOPIC. Or that we saw the former and got reinitialized before we saw the latter. Now everyone in this bug knows at least as much as I do about this code. ;)
Comment 4•17 years ago
|
||
I bumped into this when looking for something else in gdb... The topic was "profile-before-change".
Assignee | ||
Comment 5•14 years ago
|
||
I can't reproduce this any more (trunk, linux).
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•