Closed Bug 705588 (GCHangs) Opened 13 years ago Closed 13 years ago

GC-related hangs found by the hang detector

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: mccr8, Unassigned)

References

Details

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

Crash Data

I don't know if these are worth looking into, given that the likely fix for them is incremental GC. But I thought I'd bucket them here. I think the hang detector is triggered by pauses of 30 seconds or more. I spot checked a few individual crash reports. Mostly, these are GC's in a fairly short stack, but there are some where it is triggered inside a deep stack. e66cc9be-d83c-489c-a5ac-973392111126 deep inside an nsDocument::Destroy These two are a little weird: f445432a-aa29-4809-b565-9a1872111126 8fc49bae-2ddd-46da-aaa5-5bb992111126 There's a hang in nsAttrAndChildArray::Clear, which is being called by a sweep during a GC, that was triggered by je_free, that is invoked by a CC. Seems a little weird to me. Triggering a GC during a CC seems like a bad idea. If it could be scheduled 500ms after the CC or something that seems like it could be better. (Most of these hangs are CC not GC so I'm not including it in the signatures.) Some of the DOMStringFinalizer hangs are during a GC sweep.
Adding DOMStringFinalizer because all 7 hangs in there are during a GC sweep.
Crash Signature: js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int) ] → js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int) ] [@ chromehang | DOMStringFinalizer ]
js::CheckScript(JSScript*, JSScript*) is another hang during marking. A few I saw were in very deep stacks. Likewise with fun_trace. Should hangs during marking be split from hangs during scanning?
Crash Signature: js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int) ] [@ chromehang | DOMStringFinalizer ] → js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int) ] [@ chromehang | DOMStringFinalizer ] [@ chromehang | js::CheckScript(JSScript*, JSScript*) ] [@ chromehang | fun_trace ]
Depends on: IncrementalGC
DecommitFreePages is in sweep.
Crash Signature: [@ chromehang | js::gc::MarkAtomRange ] [@ chromehang | js::gc::ScanShape ] [@ chromehang | js::gc::ScanObject ] [@ chromehang | JSObject::scanSlots(js::GCMarker*) ] [@ chromehang | js::gc::PushMarkStack ] [@ chromehang | js::gc::Arena::finalize<JSOb… → [@ chromehang | js::gc::MarkAtomRange ] [@ chromehang | js::gc::ScanShape ] [@ chromehang | js::gc::ScanObject ] [@ chromehang | JSObject::scanSlots(js::GCMarker*) ] [@ chromehang | js::gc::PushMarkStack ] [@ chromehang | DecommitFreePages ] [@ chro…
I was only able to open one of the 5 or so reports with this signature, but I think TraceJS is only called from the GC.
Alias: GCHangs
Crash Signature: chromehang | js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int) ] [@ chromehang | DOMStringFinalizer ] [@ chromehang | js::CheckScript(JSScript*, JSScript*) ] [@ chromehang | fun_trace ] → chromehang | js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int) ] [@ chromehang | DOMStringFinalizer ] [@ chromehang | js::CheckScript(JSScript*, JSScript*) ] [@ chromehang | fun_trace ] [@ chromehang | TraceJSHolder ]
Severity: normal → critical
Keywords: hang
Whiteboard: [Snappy]
I'm going to mark this as P1, but really, this is probably just going to be fixed by incremental GC, so it may not be worth tracking separately. I guess it will be worth looking at once incremental GC lands, and once the hang detector relands.
Whiteboard: [Snappy] → [Snappy:P1]
(In reply to Andrew McCreight [:mccr8] from comment #5) > I'm going to mark this as P1, but really, this is probably just going to be > fixed by incremental GC, so it may not be worth tracking separately. I > guess it will be worth looking at once incremental GC lands, and once the > hang detector relands. Is this bug active now, or are we still waiting for the hang detector to land?
Hang detector isn't active, so we can't see what things look like.
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: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.