Closed Bug 1711415 Opened 3 years ago Closed 3 years ago

Assertion failure: steps > 0, at js/SliceBudget.h:76 with Debugger and WebAssembly

Categories

(Core :: JavaScript: GC, defect)

x86_64
Linux
defect

Tracking

()

VERIFIED FIXED
91 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox89 --- wontfix
firefox90 --- wontfix
firefox91 --- verified

People

(Reporter: decoder, Assigned: jonco)

References

(Regression)

Details

(Keywords: assertion, regression, testcase, Whiteboard: [bugmon:update,bisected,confirmed])

Attachments

(2 files)

The following testcase crashes on mozilla-central revision 20210516-3210b5354d3e (debug build, run with --fuzzing-safe --ion-offthread-compile=off --scalar-replace-arguments --disable-oom-functions --baseline-eager --ion-inlining=off --nursery-strings=on --ion-warmup-threshold=0):

function wasmRunWithDebugger(wast, lib, init, done) {
    let g = newGlobal({newCompartment: true});
    let dbg = new Debugger(g);
    g.eval(`
      var wasm = wasmTextToBinary('${wast}');
      var lib = ${lib || 'undefined'};
      var m = new WebAssembly.Instance(new WebAssembly.Module(wasm), lib);
    `);
    var wasmScript = dbg.findScripts().filter(s => s.format == 'wasm')[0];
    init({dbg, wasmScript, g,});
    result = g.eval("m.exports.test()");
}
gczeal(17, 3);
function b(c, d) {
    function e(f) {
        var g = {}
        f.environment.names().forEach(h => g)
        f.environment
    }
    wasmRunWithDebugger(c, d, function({ dbg }) {
        dbg.onEnterFrame = function(f) { e(f) }
    })
}
b('(module (func) (export "test" (func 0)))');

Backtrace:

received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff520d700 (LWP 12740)]
0x000055555749481a in js::gc::ParallelWorker<js::gc::WeakCacheToSweep, js::gc::WeakCacheSweepIterator>::run(js::AutoLockHelperThreadState&) ()
#0  0x000055555749481a in js::gc::ParallelWorker<js::gc::WeakCacheToSweep, js::gc::WeakCacheSweepIterator>::run(js::AutoLockHelperThreadState&) ()
#1  0x000055555746c88a in js::GCParallelTask::runTask(js::AutoLockHelperThreadState&) ()
#2  0x000055555746cb75 in js::GCParallelTask::runHelperThreadTask(js::AutoLockHelperThreadState&) ()
#3  0x0000555556e1fcf3 in js::GlobalHelperThreadState::runTaskLocked(js::HelperThreadTask*, js::AutoLockHelperThreadState&) ()
#4  0x0000555556e1dfcb in js::HelperThread::threadLoop() ()
#5  0x0000555556e1dd38 in js::HelperThread::ThreadMain(void*) ()
#6  0x0000555556e4df64 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) ()
#7  0x00007ffff7bc16ba in start_thread (arg=0x7ffff520d700) at pthread_create.c:333
#8  0x00007ffff6e4641d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
rax	0x555555886a5f	93824995584607
rbx	0x7fffffff6280	140737488315008
rcx	0x555558038748	93825037207368
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7ffff520cc70	140737305955440
rsp	0x7ffff520cc30	140737305955376
r8	0x7ffff7105770	140737338431344
r9	0x7ffff520d700	140737305958144
r10	0x0	0
r11	0x0	0
r12	0x7fffffff6308	140737488315144
r13	0x0	0
r14	0x555558039760	93825037211488
r15	0x7fffffff62d8	140737488315096
rip	0x55555749481a <js::gc::ParallelWorker<js::gc::WeakCacheToSweep, js::gc::WeakCacheSweepIterator>::run(js::AutoLockHelperThreadState&)+410>
=> 0x55555749481a <_ZN2js2gc14ParallelWorkerINS0_16WeakCacheToSweepENS0_22WeakCacheSweepIteratorEE3runERNS_25AutoLockHelperThreadStateE+410>:	movl   $0x4c,0x0
   0x555557494825 <_ZN2js2gc14ParallelWorkerINS0_16WeakCacheToSweepENS0_22WeakCacheSweepIteratorEE3runERNS_25AutoLockHelperThreadStateE+421>:	callq  0x555556a833da <abort>
Attached file Testcase

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

Start: 78e705fb75a33808a7f77ff19ce406eb3bf775a2 (20210316052743)
End: ce483363652d448558c9d99923b1870624c6c648 (20210316065056)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=78e705fb75a33808a7f77ff19ce406eb3bf775a2&tochange=ce483363652d448558c9d99923b1870624c6c648

Whiteboard: [bugmon:update,bisect] → [bugmon:update,bisected,confirmed]

NI lars based on comment 2.

Flags: needinfo?(lhansen)

There appears to be some turbulence in the GC at the moment, so we should restest this carefully: https://bugzilla.mozilla.org/show_bug.cgi?id=1711128

Flags: needinfo?(lhansen)

:decoder, can you retest this, since bug 1711128 landed?

Flags: needinfo?(choller)
Regressed by: 1676441

This is not related to bug 1676441, or to bug 1711128 for that matter.

Assignee: nobody → jcoppeard
Flags: needinfo?(choller)
No longer regressed by: 1676441

SliceBugdet::step asserts that its argument is non-zero. Usually this is a
constant that is directly passed in, but in ParallelWorker it comes from a
function that returns some estimate of the work done. The problem is that in
this case we sweep an empty hash map the estimated work returned is zero.

The fix is just to ensure that we pass at least one as the steps.

Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cbb81a00983e
Ensure we always step the budget by some amount when executing parallel GC work r=sfink
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch

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

Status: RESOLVED → VERIFIED
Keywords: bugmon

Should we uplift this or can it ride the trains to 91?

Flags: needinfo?(jcoppeard)

This seems really minor so we can let it ride the trains.

Flags: needinfo?(jcoppeard)
Flags: in-testsuite-
Regressed by: 1676441
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: