Closed Bug 1613501 Opened 4 years ago Closed 3 years ago

Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at ds/LifoAlloc.cpp:173

Categories

(Core :: JavaScript Engine, defect, P2)

x86_64
Linux
defect

Tracking

()

RESOLVED WORKSFORME
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>

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.

Flags: needinfo?(iireland)

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:

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.

Flags: needinfo?(iireland)

:sdetar, can you please (let) set a priority? Thank you!

Flags: needinfo?(sdetar)
Flags: needinfo?(sdetar)
Priority: -- → P2

Jason, decoder tells me you can help with getting a regression range?

Flags: needinfo?(jkratzer)

(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.

Flags: needinfo?(jkratzer)
Whiteboard: [jsbugmon:update,bisect]

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.

Flags: needinfo?(choller)

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.

Flags: needinfo?(choller) → needinfo?(iireland)

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.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(iireland)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.