Closed
Bug 210037
Opened 21 years ago
Closed 8 years ago
potential deadlock assertion @nsNSSComponent::ShutdownNSS()
Categories
(Core Graveyard :: Security: UI, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: darin.moz, Assigned: timeless)
References
Details
(Whiteboard: [kerh-cuz])
Attachments
(2 files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
at shutdown in a debug build, i hit this assertion:
nsDebug::Assertion(const char * 0x0012fa08, const char * 0x10119660, const char
* 0x1010e62c, int 265) line 270 + 13 bytes
nsDebug::Error(const char * 0x0012fa08, const char * 0x1010e62c, int 265) line
453 + 22 bytes
nsAutoLockBase::nsAutoLockBase(void * 0x0319be30, nsAutoLockBase::nsAutoLockType
eAutoLock) line 265 + 22 bytes
nsAutoLock::nsAutoLock(PRLock * 0x0319be30) line 172 + 21 bytes
nsNSSComponent::ShutdownNSS() line 1235
nsNSSComponent::~nsNSSComponent() line 256
nsNSSComponent::`scalar deleting destructor'() + 15 bytes
nsNSSComponent::Release(nsNSSComponent * const 0x0319bc88) line 1324 + 151 bytes
nsSupportsArray::Clear(nsSupportsArray * const 0x00a61250) line 559 + 54 bytes
nsSupportsArray::DeleteArray() line 304
nsSupportsArray::~nsSupportsArray() line 147
nsSupportsArray::`vector deleting destructor'(unsigned int 1) + 81 bytes
nsSupportsArray::Release(nsSupportsArray * const 0x00a61250) line 238 + 148 bytes
nsCOMPtr<nsISupportsArray>::~nsCOMPtr<nsISupportsArray>() line 494
nsObserverList::~nsObserverList() line 58 + 11 bytes
nsObserverList::`scalar deleting destructor'(unsigned int 1) + 15 bytes
ReleaseObserverList(nsHashKey * 0x00a61208, void * 0x00a46a08, void *
0x00000000) line 107 + 28 bytes
hashEnumerateRemove(PLDHashTable * 0x009e0fa8, PLDHashEntryHdr * 0x00a309ac,
unsigned int 25, void * 0x0012fc38) line 315 + 26 bytes
PL_DHashTableEnumerate(PLDHashTable * 0x009e0fa8, int (PLDHashTable *,
PLDHashEntryHdr *, unsigned int, void *)* 0x1001c020
hashEnumerateRemove(PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *),
void * 0x0012fc38) line 594 + 34 bytes
nsHashtable::Reset(int (nsHashKey *, void *, void *)* 0x10016ce0
ReleaseObserverList(nsHashKey *, void *, void *), void * 0x00000000) line 336 +
21 bytes
nsObjectHashtable::Reset() line 778
nsObjectHashtable::~nsObjectHashtable() line 737
nsObjectHashtable::`vector deleting destructor'(unsigned int 1) + 81 bytes
nsObserverService::~nsObserverService() line 82 + 33 bytes
nsObserverService::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsObserverService::Release(nsObserverService * const 0x009e0f58) line 72 + 142 bytes
nsCOMPtr<nsIObserverService>::~nsCOMPtr<nsIObserverService>() line 494
nsCookieService::~nsCookieService() line 335 + 68 bytes
nsCookieService::`scalar deleting destructor'() + 15 bytes
nsCookieService::Release(nsCookieService * const 0x030a3060) line 318 + 186 bytes
nsCookieService::FreeSingleton() line 304 + 26 bytes
cookieModuleDtor(nsIModule * 0x00a6c5c0) line 147
nsGenericModule::Shutdown() line 368 + 10 bytes
nsGenericModule::~nsGenericModule() line 251
nsGenericModule::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsGenericModule::Release(nsGenericModule * const 0x00a6c5c0) line 253 + 145 bytes
nsDll::Shutdown() line 378 + 18 bytes
nsFreeLibrary(nsDll * 0x00a39fb0, nsIServiceManager * 0x00000000, int 3) line 281
nsFreeLibraryEnum(nsHashKey * 0x00a3a040, void * 0x00a39fb0, void * 0x0012fe84)
line 350 + 64 bytes
hashEnumerate(PLDHashTable * 0x009b6678, PLDHashEntryHdr * 0x009b6fc4, unsigned
int 52, void * 0x0012fe68) line 115 + 26 bytes
PL_DHashTableEnumerate(PLDHashTable * 0x009b6678, int (PLDHashTable *,
PLDHashEntryHdr *, unsigned int, void *)* 0x1001bf40 hashEnumerate(PLDHashTable
*, PLDHashEntryHdr *, unsigned int, void *), void * 0x0012fe68) line 594 + 34 bytes
nsHashtable::Enumerate(int (nsHashKey *, void *, void *)* 0x1006ae50
nsFreeLibraryEnum(nsHashKey *, void *, void *), void * 0x0012fe84) line 303 + 21
bytes
nsNativeComponentLoader::UnloadAll(nsNativeComponentLoader * const 0x009b6630,
int 3) line 967
nsComponentManagerImpl::UnloadLibraries(nsIServiceManager * 0x00000000, int 3)
line 3152 + 22 bytes
nsComponentManagerImpl::Shutdown() line 895
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 733 + 11 bytes
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 144 + 13 bytes
GRE_Shutdown() line 255 + 7 bytes
main(int 4, char * * 0x002a4420) line 1678 + 5 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
potential deadlock between Monitor@9b6488 and Lock@319be30
i'm not sure how to repro this, but perhaps a careful review of the code will
reveal the problem. probably this lock is being entered while inside some
monitor. the assertion indicates that there is a codepath in which the monitor
may be entered while the lock is held. in other words, there might be a code
path such that the lock is acquired, then the monitor is acquired, and then a
fatal attempt is made to acquire the lock once again.
i noticed this with a trunk cvs build from today under WinXP.
Comment 1•21 years ago
|
||
There has been some discussion about this assertion in private mail already.
Summary: potential deadlock assertion @nsNSSComponent::ShutdownNSS() → potential deadlock assertion @nsNSSComponent::ShutdownNSS()
the conclusions we drew:
1. components (e.g. nss) should not hold locks/monitors while calling functions
(in this case NS_GetSpecialDirectory) in other modules.
2. for xpcom shutdown dougt (or some other xpcom hacker, maybe i should just do
it) can change the code so that instead of using the monitor it just swaps the
component list for a local variable and releases things using that.
personally i'll probably actually write the code for 2. such that my debug
builds will still have the monitor (#ifdef XPCOM_hacker or something) so that I
can find other people who violate 1.
Updated•20 years ago
|
Assignee: kaie → nobody
Comment 6•19 years ago
|
||
dupe of bug 200119 ?
Updated•19 years ago
|
Whiteboard: [kerh-cuz]
Updated•18 years ago
|
QA Contact: bmartin → ui
While locking in nsNSSComponent should probably be re-reviewed, it's not clear this particular report is helpful due to how much the platform has changed since it was filed.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•