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: