Closed
Bug 15073
Opened 26 years ago
Closed 26 years ago
repeatable crash in wallet shutting down
Categories
(SeaMonkey :: Passwords & Permissions, defect, P3)
SeaMonkey
Passwords & Permissions
Tracking
(Not tracked)
VERIFIED
FIXED
M10
People
(Reporter: Bienvenu, Assigned: morse)
References
Details
(Whiteboard: Fix ready.)
I was running a tip build, started up with mail, did nothing else but closed down my mail window, and crashed here: NTDLL! 77f6cde6() NTDLL! 77f67506() nsAutoLock::nsAutoLock(PRLock * 0x01b1fb00) line 129 + 12 bytes nsObserverList::RemoveObserver(nsObserverList * const 0x01b1fbb0, nsIObserver * * 0x0012fc80) line 100 nsObserverService::RemoveObserver(nsObserverService * const 0x00d9df60, nsIObserver * 0x01b1fca4, const unsigned short * 0x034026e0) line 180 + 16 bytes nsWalletlibService::~nsWalletlibService() line 59 + 50 bytes nsWalletlibService::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsWalletlibService::Release(nsWalletlibService * const 0x01b1fca0) line 91 + 96 bytes nsSupportsArray::Clear(nsSupportsArray * const 0x01b1f9a0) line 314 + 36 bytes nsSupportsArray::DeleteArray() line 59 nsSupportsArray::~nsSupportsArray() line 36 nsSupportsArray::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsSupportsArray::Release(nsSupportsArray * const 0x01b1f9a0) line 54 + 95 bytes nsObserverList::~nsObserverList() line 65 + 27 bytes nsObserverList::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsObserverList::Release(nsObserverList * const 0x01b1fbb0) line 36 + 95 bytes ReleaseObserverList(nsHashKey * 0x01b1fa30, void * 0x01b1fbb0, void * 0x00000000) line 93 + 12 bytes _hashEnumerateRemove(PLHashEntry * 0x01b1f9f0, int 3, void * 0x0012fdcc) line 223 + 26 bytes PL_HashTableEnumerateEntries(PLHashTable * 0x00d9c3c0, int (PLHashEntry *, int, void *)* 0x100153c0 _hashEnumerateRemove(PLHashEntry *, int, void *), void * 0x0012fdcc) line 368 + 15 bytes nsHashtable::Reset(int (nsHashKey *, void *, void *)* 0x10015fd0 ReleaseObserverList(nsHashKey *, void *, void *), void * 0x00000000) line 239 + 20 bytes nsObjectHashtable::Reset() line 362 nsObjectHashtable::~nsObjectHashtable() line 328 nsObjectHashtable::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsObserverService::~nsObserverService() line 58 + 31 bytes nsObserverService::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsObserverService::Release(nsObserverService * const 0x00d9df60) line 41 + 95 bytes DeleteEntry(nsHashKey * 0x00d9c0d0, void * 0x00d9c110, void * 0x00000000) line 168 + 18 bytes _hashEnumerateRemove(PLHashEntry * 0x00d9c270, int 22, void * 0x0012febc) line 223 + 26 bytes PL_HashTableEnumerateEntries(PLHashTable * 0x00cb4760, int (PLHashEntry *, int, void *)* 0x100153c0 _hashEnumerateRemove(PLHashEntry *, int, void *), void * 0x0012febc) line 368 + 15 bytes nsHashtable::Reset(int (nsHashKey *, void *, void *)* 0x1003d0c0 DeleteEntry(nsHashKey *, void *, void *), void * 0x00000000) line 239 + 20 bytes nsObjectHashtable::Reset() line 362 nsObjectHashtable::~nsObjectHashtable() line 328 nsObjectHashtable::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsServiceManagerImpl::~nsServiceManagerImpl() line 195 + 31 bytes nsServiceManagerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsServiceManagerImpl::Release(nsServiceManagerImpl * const 0x00cb4800) line 204 + 98 bytes NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 449 + 17 bytes main(int 1, char * * 0x00cb4840) line 723 + 8 bytes mainCRTStartup() line 338 + 17 bytes
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M10
Assignee | ||
Comment 2•26 years ago
|
||
When did this start happening? I haven't changed anything so something in the ifrastructure must have changed. I'll investigate.
Assignee | ||
Comment 3•26 years ago
|
||
Rick Potts, have you made any recent changes to fix bug 14727 that could be causing this bug?
Reporter | ||
Comment 4•26 years ago
|
||
I believe this started happening very recently, but I can't swear to it. Sometime yesterday, if not last night. I looked into this some - it looks like the wallet service is so long-lived that it gets shutdown after the observer service has been cleaned up. I'm a little confused how this works at all, since the wallet service itself is an observer, so how does the ref count go to 0 if an observer list is still holding on to it?
This is also happening in a build I pulled around 2:00 pm yesterday afternon.
Updated•26 years ago
|
OS: Windows NT → All
Hardware: PC → All
Comment 6•26 years ago
|
||
Happens on Mac also so maring platfor and OS as All
Comment 7•26 years ago
|
||
Does an observer hold a truly-weak ref (aka dangling pointer)? If so, scc's nsWeakPtr could help. /be
The problem is that there are two refs to walletservice: 1. Servicemanager 2. Observer And the servicemanager release happens first. So on the observer release, walletservice is destroyed. Since the walletservice has no way of knowing who called it, it does the right thing of Unregistering its observer. But since it was just called from the observer, this becomes a reentrant call to nsAutolock... Fix would be to untangle the walletservice from the observer it implements. Then walletservice wont be depedent on the order of release and the observer it implements can indepenently go away. - dp & neeti
Ok a simpler solution would be to just remove the unregistering of the observer on destruction. Logic is that whichever release happened first, the observer wont be leaked. Fix tested. It works. - neeti & dp
Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•26 years ago
|
||
Neeti just checked in the fix. Closing this out.
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 11•26 years ago
|
||
verified
Comment 12•25 years ago
|
||
Bulk move to Single Signon component, which has subsumed Password Cache.
Component: Password Cache → Single Signon
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•