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)
Core
JavaScript Engine
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.
Reporter | ||
Comment 1•13 years ago
|
||
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 ]
Reporter | ||
Comment 2•13 years ago
|
||
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
Reporter | ||
Comment 3•13 years ago
|
||
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…
Reporter | ||
Comment 4•13 years ago
|
||
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 ]
Updated•13 years ago
|
Whiteboard: [Snappy]
Reporter | ||
Comment 5•13 years ago
|
||
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]
Comment 6•13 years ago
|
||
(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?
Reporter | ||
Comment 7•13 years ago
|
||
Hang detector isn't active, so we can't see what things look like.
Reporter | ||
Comment 8•13 years ago
|
||
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.
Description
•