Assertion failure: cx_->hadResourceExhaustion(), at jit/WarpOracle.cpp:200
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox119 | --- | fixed |
People
(Reporter: lukas.bernhard, Assigned: iain)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
Steps to reproduce:
On git commit 3600e62704e5ea229199cdbf23a4d4d01889c84d the js-shell asserts when invoked as obj-x86_64-pc-linux-gnu/dist/bin/js --fuzzing-safe --fast-warmup --gc-zeal=23,20 --ion-offthread-compile=off crash.js
with the attached sample.
function main() {
function f19() {
const o20 = { };
o20.__proto__ = [3];
for (let i24 = 0; i24 < 5; i24++) {
o20[0];
}
const o31 = { };
o31.__proto__ = [];
for (let i34 = 0; i34 < 5; i34++) {
o31.length;
}
function f41() { }
for (let i44 = 16; i44 < 5; i44++) {
f41.length;
}
return "nnnnnnnnnnnn";
}
f19();
}
for (let v90 = 0; v90 < 100; v90++) {
main();
}
#0 js::jit::WarpOracle::createSnapshot (this=0x7fffffffc7b0) at js/src/jit/WarpOracle.cpp:199
#1 0x000055555811051d in js::jit::CreateWarpSnapshot (cx=cx@entry=0x7ffff6631500, mirGen=mirGen@entry=0x7ffff5509178,
script=...) at js/src/jit/Ion.cpp:1592
#2 0x000055555810cd6d in js::jit::IonCompile (cx=0x7ffff6631500, script=..., osrPc=<optimized out>)
at js/src/jit/Ion.cpp:1662
#3 js::jit::Compile (cx=cx@entry=0x7ffff6631500, script=script@entry=..., osrFrame=osrFrame@entry=0x7fffffffcb08,
osrPc=osrPc@entry=0x7ffff6603532 "\224") at js/src/jit/Ion.cpp:1855
#4 0x000055555810da59 in BaselineCanEnterAtBranch (cx=0x7ffff6631500, osrFrame=0x7fffffffcb08, pc=0x7ffff6603532 "\224",
script=...) at js/src/jit/Ion.cpp:2056
#5 IonCompileScriptForBaseline (cx=0x7ffff6631500, frame=frame@entry=0x7fffffffcb08, pc=pc@entry=0x7ffff6603532 "\224")
at js/src/jit/Ion.cpp:2108
#6 0x000055555810e38a in js::jit::IonCompileScriptForBaselineOSR (cx=0x7ffff6631500, frame=0x7fffffffcb08, frameSize=80,
pc=0x7ffff6603532 "\224", infoPtr=0x7fffffffcac0) at js/src/jit/Ion.cpp:2220
#7 0x000035fd4fa3d11b in ?? ()
#8 0x0000000000000002 in ?? ()
#9 0x00007fffffffcac0 in ?? ()
#10 0x0000000000000000 in ?? ()
Reporter | ||
Updated•8 months ago
|
Assignee | ||
Comment 1•8 months ago
|
||
Nice find. This is a finicky little issue involving monomorphic inlining and stub folding.
When we bail out and add a new entry to a folded stub, we have to notify the IonScript to prevent an unnecessary invalidation. If the stub was in an inlined script, we have to be careful to notify the right IonScript. If it was trial inlining, then this is a private ICScript, and we can find it through the inlining root. If we monomorphically inline a script containing a folded stub, we have to save a reference to the correct outer script.
What we currently don't support is the case where we trial-inline a script inside a monomorphically inlined script:
outer script
| (monomorphic inlining)
V
middle script
| (trial inlining)
V
inner script
In this case, because the innermost script is trial-inlined, we don't save a reference to the outer script, and we end up notifying the middle script.
Here's a testcase that doesn't need gczeal:
// |jit-test| --no-threads
function inner(obj, f) {
return obj.x + f();
}
function middle(obj, f) {
return inner(obj, f);
}
function outer(obj, f) {
return middle(obj, f);
}
var fs = [() => 1, () => 2];
with ({}) {}
for (var i = 0; i < 1500; i++) {
var obj = {x: 1};
obj["y" + i % 2] = 2;
outer(obj, fs[i % 2]);
}
for (var i = 0; i < 1500; i++) {
var obj = {x: 1};
obj["y" + (3 + (i % 10))] = 2;
outer(obj, fs[i % 2]);
}
One answer is to use MonomorphicInlinedStubFolding
whenever any inlining parent is monomorphically inlined, not just the direct parent.
Updated•8 months ago
|
Assignee | ||
Comment 2•8 months ago
|
||
Updated•8 months ago
|
Pushed by iireland@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/38b6d0fc67fc Store monomorphic inlining info in InlineScriptTree r=jandem
Comment 4•8 months ago
|
||
bugherder |
Description
•