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)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ginnchen+exoracle, Assigned: surkov)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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.
Assignee: aaronleventhal → surkov.alexander
Blocks: fox3access
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
Crash Signature: [@nsAccessNode::ClearCacheEntry]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: