Closed Bug 334177 Opened 20 years ago Closed 20 years ago

topcrash (not at shutdown) [@ PL_DHashTableRawRemove] called from nsGenericElement::~nsGenericElement

Categories

(Core :: DOM: Core & HTML, defect, P1)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla1.8.1alpha2

People

(Reporter: dbaron, Assigned: dbaron)

Details

(4 keywords, Whiteboard: [patch])

Crash Data

Attachments

(3 files)

Bug 237736 has tracked crashes in PL_DHashTableRawRemove called from ~nsGenericElement. It was originally filed on a shutdown crash, but has come to track both that problem and the topcrash we've been seeing. I'm filing this bug as a separate bug to analyze the topcrash. I did a detailed analysis of one of the stacks in talkback with this signature, figured out on which instruction the crash was happening (the crash is on the line: MARK_ENTRY_REMOVED(entry); assigning 0x1 into entry->keyHash. And I've finally figured out *why* this is happening -- the clearEntry callback used for sEventListenerManagersHash can mutate (shrink, most likely) the table!
Assignee: general → dbaron
Status: NEW → ASSIGNED
In particular, what I suspect is happening is that we end up with a stack something like (this entire stack is written by hand): ChangeTable PL_DHashTableOperate nsGenericElement::~nsGenericElement ... <removal of a C++-implemented event listener> nsEventListenerManager::ReleaseListeners nsEventListenerManager::RemoveAllListeners nsEventListenerManager::~nsEventListenerManager nsEventListenerManager::Release nsCOMPtr_base::~nsCOMPtr_base nsCOMPtr<nsIEventListenerManager>::~nsCOMPtr<nsIEventListenerManager> EventListenerManagerMapEntry::~EventListenerManagerMapEntry EventListenerManagerClearEntry PL_DHashTableRawRemove <== crash here on un-wind PL_DHashTableOperate nsGenericElement::~nsGenericElement
Flags: blocking1.8.1?
Flags: blocking1.8.0.3?
Summary: talkback crashes (not at shutdown) [@ PL_DHashTableRawRemove] called from nsGenericElement::~nsGenericElement → topcrash (not at shutdown) [@ PL_DHashTableRawRemove] called from nsGenericElement::~nsGenericElement
FWIW, I filed bug 334180 on making pldhash assert about this type of problem.
Attached patch trunk patch — — Splinter Review
The branch patch will look a bit different thanks to bug 315901.
Attachment #218870 - Flags: superreview?(jst)
Attachment #218870 - Flags: review?(jst)
Attachment #218872 - Flags: superreview?(jst)
Attachment #218872 - Flags: review?(jst)
Attachment #218872 - Flags: approval1.8.0.3?
Attachment #218872 - Flags: approval-branch-1.8.1?(jst)
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.8.1alpha2
Comment on attachment 218870 [details] [diff] [review] trunk patch r+sr=jst
Attachment #218870 - Flags: superreview?(jst)
Attachment #218870 - Flags: superreview+
Attachment #218870 - Flags: review?(jst)
Attachment #218870 - Flags: review+
Attachment #218872 - Flags: superreview?(jst)
Attachment #218872 - Flags: superreview+
Attachment #218872 - Flags: review?(jst)
Attachment #218872 - Flags: review+
Attachment #218872 - Flags: approval-branch-1.8.1?(jst)
Attachment #218872 - Flags: approval-branch-1.8.1+
Checked in to trunk and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.3+
Comment on attachment 218872 [details] [diff] [review] patch for 1.8 branch aproved for 1.8.0 branch, a=dveditz for drivers
Attachment #218872 - Flags: approval1.8.0.3? → approval1.8.0.3+
Fix checked in to MOZILLA_1_8_0_BRANCH.
Keywords: fixed1.8.0.3
no longer appearing on topcrash reports for branch. However, PL_DHashTableRawRemove still appears on trunk topcrash reports. But that may be related to bug 234169. Can't tell right now as incedent query is broken.
Status: RESOLVED → VERIFIED
Crash Signature: [@ PL_DHashTableRawRemove]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: