Closed Bug 210037 Opened 21 years ago Closed 8 years ago

potential deadlock assertion @nsNSSComponent::ShutdownNSS()

Categories

(Core Graveyard :: Security: UI, defect)

Other Branch
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: darin.moz, Assigned: timeless)

References

Details

(Whiteboard: [kerh-cuz])

Attachments

(2 files)

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.
There has been some discussion about this assertion in private mail already.
Summary: potential deadlock assertion @nsNSSComponent::ShutdownNSS() → potential deadlock assertion @nsNSSComponent::ShutdownNSS()
Attached file "previous" (deleted) —
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.
Kai
Assignee: ssaux → kaie
Blocks: 160540
Blocks: 209804
Assignee: kaie → nobody
Product: PSM → Core
Assignee: nobody → timeless
Status: NEW → ASSIGNED
dupe of bug 200119 ?
Whiteboard: [kerh-cuz]
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: