Closed
Bug 391203
Opened 17 years ago
Closed 17 years ago
Firefox crashed when closing DOM inspector window [@nsAccessNode::ClearCacheEntry]
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ginnchen+exoracle, Assigned: surkov)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
(deleted),
text/plain
|
Details |
Steps,
1) Press Control+Shift+I to get DOM inspector window
2) Press Control+W to close it
3) Repeat 1)-2), usually you will get a core dump in less than 10 times.
The stack may be different.
Typically it looks like,
#5 <signal handler called>
#6 0x04244483 in ?? ()
#7 0xb7cd2a11 in nsQueryInterface::operator() (this=0xbffdfbd4,
aIID=@0xb225d7dc, answer=0xbffdfbc0) at nsCOMPtr.cpp:47
#8 0xb21c0da4 in nsCOMPtr<nsPIAccessNode>::assign_from_qi (this=0xbffdfc0c,
qi={mRawPtr = 0xb2280a88}, aIID=@0xb225d7dc)
at ../../../dist/include/xpcom/nsCOMPtr.h:1244
#9 0xb21c0e07 in nsCOMPtr (this=0xbffdfc0c, qi={mRawPtr = 0xb2280a88})
at ../../../dist/include/xpcom/nsCOMPtr.h:645
#10 0xb21ba64c in nsAccessNode::ClearCacheEntry (aKey=0xb2280a4c,
aAccessNode=@0x9080608, aUserArg=0x0) at nsAccessNode.cpp:788
#11 0xb21be019 in nsBaseHashtable<nsVoidPtrHashKey, nsCOMPtr<nsIAccessNode>, nsIAccessNode*>::s_EnumStub (table=0x8cefe3c, hdr=0x9080600, number=1,
arg=0xbffdfcdc) at ../../../dist/include/xpcom/nsBaseHashtable.h:346
#12 0xb7cce6a0 in PL_DHashTableEnumerate (table=0x8cefe3c,
etor=0xb21bdfcc <nsBaseHashtable<nsVoidPtrHashKey, nsCOMPtr<nsIAccessNode>, nsIAccessNode*>::s_EnumStub(PLDHashTable*, PLDHashEntryHdr*, unsigned int, void*---Type <return> to continue, or q <return> to quit---
)>, arg=0xbffdfcdc) at pldhash.c:724
#13 0xb21c33b2 in nsBaseHashtable<nsVoidPtrHashKey, nsCOMPtr<nsIAccessNode>, nsIAccessNode*>::Enumerate (this=0x8cefe3c,
enumFunc=0xb21ba60a <nsAccessNode::ClearCacheEntry(void const*, nsCOMPtr<nsIAccessNode>&, void*)>, userArg=0x0)
at ../../../dist/include/xpcom/nsBaseHashtable.h:221
#14 0xb21baf29 in nsAccessNode::ClearCache (aCache=@0x8cefe3c)
at nsAccessNode.cpp:797
#15 0xb21cc78d in nsDocAccessible::Shutdown (this=0x8cefdd0)
at nsDocAccessible.cpp:551
#16 0xb21cbf63 in nsDocAccessible::ShutdownChildDocuments (this=0x922ee00,
aStart=0x90346b8) at nsDocAccessible.cpp:575
#17 0xb21cc68f in nsDocAccessible::Shutdown (this=0x922ee00)
at nsDocAccessible.cpp:532
#18 0xb21f5cb3 in nsRootAccessible::Shutdown (this=0x922ee00)
at nsRootAccessible.cpp:902
#19 0xb21c8679 in nsDocAccessible::Destroy (this=0x922ee00)
at nsDocAccessible.cpp:522
#20 0xb21f6c92 in nsRootAccessible::HandleEventWithTarget (this=0x922ee00,
aEvent=0x918aa5c, aTargetNode=0x9362cc4) at nsRootAccessible.cpp:597
#21 0xb21f8045 in nsRootAccessible::HandleEvent (this=0x922ee00,
aEvent=0x918aa5c) at nsRootAccessible.cpp:557
(gdb) frame 7
#7 0xb7cd2a11 in nsQueryInterface::operator() (this=0xbffdfbd4,
aIID=@0xb225d7dc, answer=0xbffdfbc0) at nsCOMPtr.cpp:47
47 status = mRawPtr->QueryInterface(aIID, answer);
(gdb) whats this
0xb2280a88 <_ZTV23nsXULTreeitemAccessible+712>: 0xb224fc2c <_ZThn32_N23nsXULTreeitemAccessible14QueryInterfaceERK4nsIDPPv>
Well, I could not reliably reproduce this problem now.
But I did see the crash time by time.
Updated•17 years ago
|
Assignee: aaronleventhal → surkov.alexander
Updated•17 years ago
|
Blocks: fox3access
Comment 2•17 years ago
|
||
Marco or Surkov, can either of you duplicate this?
Not reproducible with latest trunk.
Close as WFM for now.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Updated•14 years ago
|
Crash Signature: [@nsAccessNode::ClearCacheEntry]
You need to log in
before you can comment on or make changes to this bug.
Description
•