1723942 - Assertion failure: nurseryTenuredCount != 0, at js/src/gc/Pretenuring.h:129

Status: VERIFIED FIXED

(Core :: JavaScript: GC, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20210803-524aef2e3307 (--enable-debug build, run with --fuzzing-safe --cpu-count=2 --ion-offthread-compile=off):

function mapfloor(a0) {
  var b97 = a0.map(function(v17) {
    return Math.floor(v17);
  });
  var res = "";
  for (var i28 = 0; i28 < b97.length; {} ? async Function => {} : this + '')
    res += b97[i28] + ",";
}
mapfloor([1,2]);

Backtrace:

received signal SIGSEGV, Segmentation fault.
0x000055555754e8cb in js::TenuringTracer::onStringEdge(JSString*) ()
#0  0x000055555754e8cb in js::TenuringTracer::onStringEdge(JSString*) ()
#1  0x0000555557545467 in JSRope::traceChildren(JSTracer*) ()
#2  0x0000555557553a49 in js::Nursery::collectToStringFixedPoint(js::TenuringTracer&) ()
#3  0x000055555756ad1d in js::Nursery::doCollection(JS::GCReason) ()
#4  0x0000555557569d89 in js::Nursery::collect(JS::GCOptions, JS::GCReason) ()
#5  0x00005555574fa9a1 in js::gc::GCRuntime::collectNursery(JS::GCOptions, JS::GCReason, js::gcstats::PhaseKind) ()
#6  0x00005555575002fc in js::gc::GCRuntime::minorGC(JS::GCReason, js::gcstats::PhaseKind) ()
#7  0x00005555574ae040 in JSObject* js::gc::GCRuntime::tryNewNurseryObject<(js::AllowGC)1>(JSContext*, unsigned long, unsigned long, JSClass const*, js::gc::AllocSite*) ()
#8  0x00005555574adb83 in JSObject* js::AllocateObject<(js::AllowGC)1>(JSContext*, js::gc::AllocKind, unsigned long, js::gc::InitialHeap, JSClass const*, js::gc::AllocSite*) ()
#9  0x0000555556b9f0d1 in js::NativeObject::create(JSContext*, js::gc::AllocKind, js::gc::InitialHeap, JS::Handle<js::Shape*>, js::gc::AllocSite*) ()
#10 0x0000555556c186d3 in js::NewPlainObjectOptimizedFallback(JSContext*, JS::Handle<js::Shape*>, js::gc::AllocKind, js::gc::InitialHeap) ()
#11 0x00001b75e126a22d in ?? ()
[...]
#20 0x0000000000000000 in ?? ()
rax	0x55555575bee4	93824994361060
rbx	0x7fffffffb658	140737488336472
rcx	0x555558120a70	93825038158448
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffffb570	140737488336240
rsp	0x7fffffffb570	140737488336240
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f99840	140737353717824
r10	0x0	0
r11	0x0	0
r12	0x3b1255cec9c8	64949935065544
r13	0x324cc16b9400	55305243956224
r14	0x324cc16b9400	55305243956224
r15	0x7fffffffb650	140737488336464
rip	0x55555754e8cb <js::TenuringTracer::onStringEdge(JSString*)+139>
=> 0x55555754e8cb <_ZN2js14TenuringTracer12onStringEdgeEP8JSString+139>:	movl   $0x81,0x0
   0x55555754e8d6 <_ZN2js14TenuringTracer12onStringEdgeEP8JSString+150>:	callq  0x555556b0473a <abort>

Marking s-s until investigated, as this is a GC assert. Note that the test runs for about 10 seconds before asserting.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Jon Coppeard (:jonco) (PTO until 5th Jan)]

The unknown catch-all allocation site doesn't get its nursery allocation/tenured counts reset if it's only used from JIT code.

This is not security sensitive.

Comment 4

[Jon Coppeard (:jonco) (PTO until 5th Jan)]

Attachment: Bug 1723942 - Reset unknown catch-all allocation site if it wasn't on the allocatedSites list r?jandem

Like the optimized catch-all allocation site, the unknown one doesn't get put
on the allocatedSites list if it's only used by optimized JIT code. This fix is
to check this at the end like we already do for the optimized one. Getting this
wrong doesn't really affect anything since these numbers aren't used for the
unknown alloc site.

I tried making a test for this but it took too long to overflow the count in
debug builds.

Comment 5

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20210804214554-a72c2fe44761.
The bug appears to have been introduced in the following build range:

Start: 291d5337daa3c3c3a3e7bdc13360e53f24700380 (20210719151940)
End: 80dc8f306af0182c503cd73b7eebcd44544e89f4 (20210719152549)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=291d5337daa3c3c3a3e7bdc13360e53f24700380&tochange=80dc8f306af0182c503cd73b7eebcd44544e89f4

Comment 6

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

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

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e03dc806934d
Reset unknown catch-all allocation site if it wasn't on the allocatedSites list r=jandem

Comment 8

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/e03dc806934d

Comment 9

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Verified bug as fixed on rev mozilla-central 20210806033613-c8c5ee96321f.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Is there a user-facing issue caused by this bug which would make us want to consider ESR91 uplift? Please nominate if so.

Comment 11

[Jon Coppeard (:jonco) (PTO until 5th Jan)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #10)
No user-facing issue here.