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

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[lukas.bernhard]

Attachment: program_20210425141405_48DBB129-A32D-73E2-02CC-F07AF9101DEF_deterministic_129.js

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Similar to Bug 1613501 and others, the attached testcase crashes on mozilla-central (git commit 7a2cf04303cf6d4b684905a1af936b6da5e7ef59).
WarpBuilder::walkEnvironmentChain is called with numHops=112, loop iteration 110 ends up in LifoAlloc::newChunkWithCapacity which triggers the assertion as the allocation request is in an infallible scope.

Actual results:

Execution crashes with the following backtrace:

Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at /home/user/gecko-dev/js/src/ds/LifoAlloc.cpp:173
AddressSanitizer:DEADLYSIGNAL
=================================================================
==702089==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x56510aa6afee bp 0x7ffc7e486930 sp 0x7ffc7e486880 T0) 
==702089==The signal is caused by a WRITE memory access.
==702089==Hint: address points to the zero page.
    #0 0x56510aa6afee in js::LifoAlloc::newChunkWithCapacity(unsigned long, bool) /home/user/gecko-dev/js/src/ds/LifoAlloc.cpp:172:3
    #1 0x56510aa6b2ad in js::LifoAlloc::getOrCreateChunk(unsigned long) /home/user/gecko-dev/js/src/ds/LifoAlloc.cpp:225:30
    #2 0x56510aa6b84c in js::LifoAlloc::allocImplColdPath(unsigned long) /home/user/gecko-dev/js/src/ds/LifoAlloc.cpp:235:30
    #3 0x56510b813643 in allocImpl /home/user/gecko-dev/js/src/ds/LifoAlloc.h:762:12
    #4 0x56510b813643 in allocInfallible /home/user/gecko-dev/js/src/ds/LifoAlloc.h:857:24
    #5 0x56510b813643 in js::jit::TempAllocator::allocateInfallible(unsigned long) /home/user/gecko-dev/js/src/jit/JitAllocPolicy.h:45:31
    #6 0x56510c1485ca in operator new /home/user/gecko-dev/js/src/jit/JitAllocPolicy.h:135:18
    #7 0x56510c1485ca in operator new /home/user/gecko-dev/js/src/jit/MIR.h:961:12
    #8 0x56510c1485ca in js::jit::MEnclosingEnvironment::New(js::jit::TempAllocator&, js::jit::MDefinition*) /home/user/gecko-dev/js/src/jit/MIR.h:11013:12
    #9 0x56510c087fa8 in walkEnvironmentChain /home/user/gecko-dev/js/src/jit/WarpBuilder.cpp:1629:25
    #10 0x56510c087fa8 in js::jit::WarpBuilder::build_GetAliasedVar(js::BytecodeLocation) /home/user/gecko-dev/js/src/jit/WarpBuilder.cpp:1639:22
    #11 0x56510c052bac in js::jit::WarpBuilder::buildBody() /home/user/gecko-dev/js/src/jit/WarpBuilder.cpp:680:19
    #12 0x56510c04ffa1 in js::jit::WarpBuilder::build() /home/user/gecko-dev/js/src/jit/WarpBuilder.cpp:290:8
    #13 0x56510bfb2a22 in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) /home/user/gecko-dev/js/src/jit/Ion.cpp:1582:18
    #14 0x56510bfb6cc9 in IonCompile /home/user/gecko-dev/js/src/jit/Ion.cpp:1723:38
    #15 0x56510bfb6cc9 in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) /home/user/gecko-dev/js/src/jit/Ion.cpp:1908:24
    #16 0x56510bfb8dd9 in BaselineCanEnterAtBranch /home/user/gecko-dev/js/src/jit/Ion.cpp:2109:25
    #17 0x56510bfb8dd9 in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned char*) /home/user/gecko-dev/js/src/jit/Ion.cpp:2160:12
    #18 0x56510bfba898 in js::jit::IonCompileScriptForBaselineOSR(JSContext*, js::jit::BaselineFrame*, unsigned int, unsigned char*, js::jit::IonOsrTempData**) /home/user/gecko-dev/js/src/jit/Ion.cpp:2272:8
    #19 0x16f701454a76  (<unknown module>)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/user/gecko-dev/js/src/ds/LifoAlloc.cpp:172:3 in js::LifoAlloc::newChunkWithCapacity(unsigned long, bool)
==702089==ABORTING

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

Iain: This looks like a ballast issue on a synthetic test case; can you take a look?

Comment 3

[Iain Ireland [:iain]]

The issue is that we can just barely allocate too many MEnclosingEnvironments here before hitting the function nesting limit.

Not going to hit this by accident, but we might as well fix it anyway.

Comment 4

[Iain Ireland [:iain]]

Attachment: Bug 1710089: Add ensureBallast in walkEnvironmentChain r=mgaudet

We need the x_n variables in the testcase so that there are enough hops.

OOM handling delenda est.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/afed3145e08b
Add ensureBallast in walkEnvironmentChain r=mgaudet

Comment 6

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/afed3145e08b