Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at ds/LifoAlloc.cpp:173
Categories
(Core :: JavaScript Engine, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox74 | --- | wontfix |
firefox75 | --- | fix-optional |
People
(Reporter: decoder, Unassigned)
Details
(4 keywords)
The following testcase crashes on mozilla-central revision 20200204-a117660624ec (build with --enable-debug, run with --fuzzing-safe --no-threads --ion-warmup-threshold=1 --baseline-warmup-threshold=0 --disable-oom-functions):
Object.defineProperty(this, "utils", { value:{ newGlobal: newGlobal }});
var lfNoDebugger = false;
newGlobal = function(o) {
let g = utils.newGlobal(o);
g['gcparam'] = function() {};
g['enableGeckoProfiling'] = function() {};
if (lfNoDebugger)
g['Debugger'] = undefined;
return g;
}
function f86() {
var arr = [];
x97 = BigInt(-1);
for (var i98 = (x97++); i98 < 12; i98++) {
var g19 = newGlobal();
var o63 = new g19.FakeDOMObject();
o63[0] = 1;
arr.push(o63);
}
var res;
for (var i98 = 0; --''.trimLeft | this; x1++) {}
}
f86();
Backtrace:
received signal SIGSEGV, Segmentation fault.
0x0000555555f82e13 in js::LifoAlloc::newChunkWithCapacity(unsigned long, bool) ()
#0 0x0000555555f82e13 in js::LifoAlloc::newChunkWithCapacity(unsigned long, bool) ()
#1 0x0000555555f83011 in js::LifoAlloc::getOrCreateChunk(unsigned long) ()
#2 0x0000555555f8328b in js::LifoAlloc::allocImplColdPath(unsigned long) ()
#3 0x0000555555a02e9f in js::LifoAlloc::allocInfallible(unsigned long) ()
#4 0x0000555556634e91 in js::jit::IonBuilder::initializedLength(js::jit::MDefinition*) ()
#5 0x0000555556637624 in js::jit::IonBuilder::initOrSetElemDense(js::TemporaryTypeSet::DoubleConversion, js::jit::MDefinition*, js::jit::MDefinition*, js::jit::MDefinition*, bool, bool*) ()
#6 0x000055555662ac4e in js::jit::IonBuilder::initOrSetElemTryDense(bool*, js::jit::MDefinition*, js::jit::MDefinition*, js::jit::MDefinition*, bool) ()
#7 0x000055555660dc70 in js::jit::IonBuilder::jsop_setelem() ()
#8 0x00005555565faa0e in js::jit::IonBuilder::inspectOpcode(JSOp, bool*) ()
#9 0x00005555565f62e8 in js::jit::IonBuilder::traverseBytecode() ()
#10 0x00005555565ed09b in js::jit::IonBuilder::build() ()
#11 0x00005555565e162a in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned int, unsigned char*, bool) ()
#12 0x00005555565e2a2d in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned int, unsigned char*) ()
#13 0x00005555565e2ffd in js::jit::IonCompileScriptForBaselineOSR(JSContext*, js::jit::BaselineFrame*, unsigned int, unsigned char*, js::jit::IonOsrTempData**) ()
#14 0x0000043d0a7ba897 in ?? ()
#15 0x00007fffffffafd8 in ?? ()
#16 0x00007fffffffaf30 in ?? ()
#17 0x0000000000000000 in ?? ()
rax 0x555556f341ef 93825019363823
rbx 0x7ffff5ee5d60 140737319427424
rcx 0x555557f3d840 93825036179520
rdx 0x0 0
rsi 0x7ffff6efd770 140737336301424
rdi 0x7ffff6efc540 140737336296768
rbp 0x7fffffffa870 140737488332912
rsp 0x7fffffffa850 140737488332880
r8 0x7ffff6efd770 140737336301424
r9 0x7ffff7f9cd00 140737353731328
r10 0x58 88
r11 0x7ffff6ba47a0 140737332791200
r12 0x7ffff5c6a720 140737316824864
r13 0x7ffff5c6ab18 140737316825880
r14 0x7fffffffa8c0 140737488332992
r15 0x7ffff5ee5d60 140737319427424
rip 0x555555f82e13 <js::LifoAlloc::newChunkWithCapacity(unsigned long, bool)+307>
=> 0x555555f82e13 <_ZN2js9LifoAlloc20newChunkWithCapacityEmb+307>: movl $0xad,0x0
0x555555f82e1e <_ZN2js9LifoAlloc20newChunkWithCapacityEmb+318>: callq 0x5555557fb7a6 <abort>
Comment 1•4 years ago
|
||
Usually these bugs are about the lack the reserved ballast space in a loop controlled by the user input.
However, I am not sure to see where things should be patched with the current stack trace, the minifaction likely caused the signature to change.
Comment 2•4 years ago
|
||
In a variety of places, we are looping over a typeset and attaching constraints. However, because we are using FakeDOMObjects, the maximum size of an object group is 16, not 8. (In this particular case, it looks like we have 13 keys in the typeset.) It seems like our ballast is not calibrated for object groups of that size.
A list of the places I see us looping over object keys:
- TemporaryTypeSet::getKnownClass: We see this 4 times for the same TemporaryTypeSet
- TemporaryTypeSet::hasObjectFlags: We see this 7 times for the same TemporaryTypeSet
- TemporaryTypeSet::convertDoubleElements
- DenseNativeElementType
- PropertyWriteNeedsTypeBarrier
Every time we call one of these functions, we allocate a constraint (64 bytes) for every entry in the typeset, which adds up to overflowing our ballast. In every case, the typeset we're iterating over is the same.
There are many ways to fix this problem. Mostly, though, I just can't wait until Warp lets us delete all this nonsense.
Comment 3•4 years ago
|
||
:sdetar, can you please (let) set a priority? Thank you!
Updated•4 years ago
|
Updated•4 years ago
|
Comment 4•4 years ago
|
||
Jason, decoder tells me you can help with getting a regression range?
Comment 5•4 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #4)
Jason, decoder tells me you can help with getting a regression range?
I do not think the regression range would be necessary for solving issue.
Updated•4 years ago
|
Updated•4 years ago
|
Hi Christian
We are checking on really old bugs to see if we can close some or not.
Im wondering if this bug can be closed or it should stay open.
Do you know?
thanks.
Reporter | ||
Comment 7•3 years ago
|
||
I can't reproduce this with the test in comment 0 anymore, but only Iain would be able to tell if we really fixed this.
Comment 8•3 years ago
|
||
This has been fixed through the power of procrastination. As I mentioned in comment 1, the move from Ion to Warp eliminated typesets and constraints, so the buggy code no longer exists.
Description
•