Assertion failure: steps > 0, at js/SliceBudget.h:76 with Debugger and WebAssembly
Categories
(Core :: JavaScript: GC, defect)
Tracking
()
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>
Reporter | ||
Comment 1•3 years ago
|
||
Comment 2•3 years ago
|
||
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
Comment 4•3 years ago
|
||
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
Comment 5•3 years ago
|
||
:decoder, can you retest this, since bug 1711128 landed?
Assignee | ||
Comment 6•3 years ago
|
||
This is not related to bug 1676441, or to bug 1711128 for that matter.
Assignee | ||
Comment 7•3 years ago
|
||
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
Comment 9•3 years ago
|
||
bugherder |
Comment 10•3 years ago
|
||
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.
Comment 11•3 years ago
|
||
Should we uplift this or can it ride the trains to 91?
Assignee | ||
Comment 12•3 years ago
|
||
This seems really minor so we can let it ride the trains.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•