1582251 - Crash in [@ js::ConstraintTypeSet::sweep] with use-after-free through [@ mozilla::ContainerState::ProcessDisplayItems]

Status: RESOLVED DUPLICATE of bug 1112741

(Core :: JavaScript: GC, defect)

Description

[Christian Holler (:decoder)]

Attachment: Alloc/Free Stacks for PHC report

This bug is for crash report bp-b5ef1321-f269-4af2-8753-06fe50190916.

Top 10 frames of crashing thread:

0 xul.dll js::ConstraintTypeSet::sweep js/src/vm/TypeInference.cpp:4249
1 xul.dll js::jit::JitScript::sweepTypes js/src/vm/TypeInference.cpp:4484
2 xul.dll js::gc::IncrementalProgress js::gc::GCRuntime::sweepTypeInformation js/src/gc/GC.cpp:5643
3 xul.dll js::gc::IncrementalProgress sweepaction::SweepActionSequence::run js/src/gc/GC.cpp:6042
4 xul.dll js::gc::IncrementalProgress sweepaction::SweepActionForEach<js::gc::SweepGroupZonesIter, JSRuntime*>::run js/src/gc/GC.cpp:6077
5 xul.dll js::gc::IncrementalProgress sweepaction::SweepActionSequence::run js/src/gc/GC.cpp:6042
6 xul.dll js::gc::IncrementalProgress sweepaction::SweepActionForEach<js::gc::SweepGroupsIter, JSRuntime*>::run js/src/gc/GC.cpp:6077
7 xul.dll js::gc::IncrementalProgress js::gc::GCRuntime::performSweepActions js/src/gc/GC.cpp:6210
8 xul.dll void js::gc::GCRuntime::incrementalSlice js/src/gc/GC.cpp:6741
9 xul.dll js::gc::GCRuntime::IncrementalResult js::gc::GCRuntime::gcCycle js/src/gc/GC.cpp:7152

The crash stack is generic JS GC, but this is a PHC crash report, so we do have the allocation and free stacks for this use-after-free (see attachment).

Based on that, it looks like a Layout bug.

Comment 1

[Christian Holler (:decoder)]

Since the crash trace is in JS GC and the alloc/free locations look to me as if they have no direct connection to the JS runtime, it is well possible that this is a mismatched stack case where the memory was freed, a pointer kept dangling in the JS engine, then the memory got reallocated and freed again (hence overwriting the stored stacks) and then the original dangling pointer was used. In that case, the report might not be actionable.

Comment 2

[Matt Woodrow (:mattwoodrow)]

(In reply to Christian Holler (:decoder) from comment #1)

Since the crash trace is in JS GC and the alloc/free locations look to me as if they have no direct connection to the JS runtime, it is well possible that this is a mismatched stack case where the memory was freed, a pointer kept dangling in the JS engine, then the memory got reallocated and freed again (hence overwriting the stored stacks) and then the original dangling pointer was used. In that case, the report might not be actionable.

Agreed on this. The allocation/free from the report should all be happening with a single paint, so once we're running JS it shouldn't be owned by painting code.

Moving to JS GC, but I'm not sure it's super actionable.