1894722 - Crash in [@ js::gc::TenuringTracer::relocateDependentStringChars<T>]

Status: RESOLVED DUPLICATE of bug 1893984

(Core :: JavaScript Engine, defect, P3)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

12 Firefox for Android 127.0a1 crashes from 10 installs.

Crash report: https://crash-stats.mozilla.org/report/index/1bcdb428-f6e0-4676-8a03-fd3bb0240502

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames:

0  libxul.so  js::gc::TenuringTracer::relocateDependentStringChars<char16_t>(JSDependentStr...  js/src/gc/Tenuring.cpp:1043
0  libxul.so  js::gc::TenuringTracer::collectToStringFixedPoint()  js/src/gc/Tenuring.cpp:1146
1  libxul.so  js::Nursery::doCollection(js::gc::AutoGCSession&, JS::GCOptions, JS::GCReason)  js/src/gc/Nursery.cpp:1520
1  libxul.so  js::Nursery::collect(JS::GCOptions, JS::GCReason)  js/src/gc/Nursery.cpp:1275
2  libxul.so  js::gc::GCRuntime::collectNursery(JS::GCOptions, JS::GCReason, js::gcstats::P...  js/src/gc/GC.cpp:4762
3  libxul.so  js::gc::GCRuntime::collectNurseryFromMajorGC(JS::GCReason)  js/src/gc/GC.cpp:3905
3  libxul.so  js::gc::GCRuntime::endPreparePhase(JS::GCReason)  js/src/gc/GC.cpp:2842
3  libxul.so  js::gc::GCRuntime::incrementalSlice(js::SliceBudget&, JS::GCReason, bool)  js/src/gc/GC.cpp:3745
4  libxul.so  js::gc::GCRuntime::gcCycle(bool, js::SliceBudget const&, JS::GCReason)  js/src/gc/GC.cpp:4334
5  libxul.so  js::gc::GCRuntime::collect(bool, js::SliceBudget const&, JS::GCReason)  js/src/gc/GC.cpp:4525

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Crash has Swept Tenured Pattern as dereferenced pointer; marking confidential, and needinfoing Steve as I suspect he's the best person to peek here.

I wonder if this is related to the recent bunch of string crashes

Comment 2

[Steve Fink [:sfink] [:s:]]

None of the handful of bugs that I recently fixed in this stuff seem like they'd result in looking at swept tenured memory. They all ended up with stale string data pointers pointing into the malloc heap, not the GC heap.

Bug 1894428 could conceivably result in this, though I don't see how in practice. That only causes problems with chars data again.

Bug 1895628 deletes the crashing code and a bunch of code surrounding it, fwiw. Which might fix this, but more likely would shift it to where we walk up the chain of base strings.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1881995

Comment 4

[Alex Thayer [:alexical] (she/her)]

Okay, so I think I have thought of a new class of failure, but I still don't see how we get from it to this bug or Bug 1894428, but maybe you have thoughts there.

Let rope be a rope string.
Let foo be rope's leftmost child.
Let E be the only edge to rope.
Let ASSC be an AutoStableStringChars pointing to foo's chars (and holding an edge to foo)

Do something which causes rope to be flattened, and have it reuse foo's buffer.
Now foo is a dependent string on rope, has lost the NON_DEDUP bit, and rope has both DEPENDED_ON_BIT and NON_DEDUP_BIT, and rope has two edges: E and the edge from foo.
Do something which drops E
Atomize foo, resulting in atom. Since foo has neither the NON_DEDUP bit nor the DEPENDED_ON_BIT, we determine we can replace it with an atom ref.

Now foo is an atom ref pointing to atom, so there are no edges into rope, but ASSC still points to rope's chars, and the buffer can be freed during GC.

I don't think any of our patches fix this particular issue, but I don't see how it shows up as any of the failures we have observed. Thoughts?

EDIT: my brain short-circuited. This is in fact fixed by the more recent patch in Bug 1894428. I think it's still a different class of problem though since it works with nursery strings (?)

Comment 5

[Alex Thayer [:alexical] (she/her)]

Okay, looking closer, I think this is just fixed by bug 1893984. The build ID timeline of crashes starting and stopping lines up identically with that landing.