Closed Bug 705577 Opened 13 years ago Closed 12 years ago

hang in nsDocument::Destroy found by hang detector

Categories

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

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: mccr8, Unassigned)

References

Details

(Keywords: hang, Whiteboard: [Snappy:P2])

Crash Data

I was looking through the chromehangs in crash reporter, and found there was one in PL_DHashTableFinish, at #52 (so not extremely severe).  All of the ones I found (about a dozen) are happening somewhere in ~RuleCascadeData, some directly, some inside a ~RuleHash subcall.  (to see this, click on show/hide other threads)

89fa8fb2-1c4b-4f9a-ab6f-931692111126
18397b6c-8dbd-4ac6-8063-ea2fe2111126
bp-89fa8fb2-1c4b-4f9a-ab6f-931692111126
cd596e45-4011-4003-811a-8f8212111125

in ~RuleHash, but not ~RuleCascadeData:
8488d582-992c-44e4-a623-328962111125

One has the comment "Saving All Windows/Tabs".
Is there any evidence there aren't a whole bunch of different stacks (for destroying different things) related to this?  (In other words, are you attributing the bug too far down the stack?)
Oh, good point.  I looked over most of the reports again, and looking over the deeper parts of the stack, they are all inside of nsDocument::Destroy, which probably can be an expensive operation.  The reasons didn't seem to be too similar to my inexperienced eye.  One was a force quit, etc.

I guess this could be resolved incomplete, or changed over to blame nsDocument::Destroy.  I wonder how many of the hangs bucket into nsDocument::Destroy.
Component: Style System (CSS) → DOM: Core & HTML
QA Contact: style-system → general
Summary: possible hang in ~RuleCascadeData/~RuleHash during PL_DHashTableFinish → possible hang in nsDocument::Destroy found by hang detector
Severity: major → critical
Crash Signature: [@ chromehang | PL_DHashTableFinish] → [@ chromehang | PL_DHashTableFinish] [@ chromehang | AtomSelector_ClearEntry ]
Whiteboard: [Snappy]
Marking P2 because these hangs are not very common (around 70 for PL_DHashTableFinish and 231 for AtomSelector_ClearEntry), and may be most common on shutdown when a bunch of large DOMs are being taken down.
Summary: possible hang in nsDocument::Destroy found by hang detector → hang in nsDocument::Destroy found by hang detector
Whiteboard: [Snappy] → [Snappy:P2]
This style of hang detector seems to be obsolete, so I think it makes sense to close these hangs, and file new reports for things the new hang detector finds.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.