1427764 - Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.) · js::LifoAlloc::newChunkWithCapacity

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Alex Gaynor [:Alex_Gaynor]]

This bug was found by Google's OSS-Fuzz running their custom internal JS fuzzer. I am refiling it in our issue tracker.

[Environment] ASAN_OPTIONS = redzone=256:strict_memcmp=0:allow_user_segv_handler=1:allocator_may_return_null=1:handle_sigfpe=1:handle_sigbus=1:detect_stack_use_after_return=0:alloc_dealloc_mismatch=0:print_scariness=1:max_uar_stack_size_log=16:detect_odr_violation=0:handle_sigill=1:coverage=0:use_sigaltstack=1:fast_unwind_on_fatal=1:detect_leaks=0:print_summary=1:handle_abort=1:check_malloc_usable_size=0:detect_container_overflow=1:symbolize=0:handle_segv=1

/mnt/scratch0/clusterfuzz/slave-bot/builds/clusterfuzz-builds-no-engine_spidermonkey_6aad6e0d14f81d36f48dbd887aa56b38e87859f7/revisions/js --cpu-count=2 --disable-oom-functions --fuzzing-safe --ion-eager /mnt/scratch0/clusterfuzz/slave-bot/inputs/fuzzer-testcases/fuzz-307.js

Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at mozilla-central/js/src/ds/LifoAlloc.cpp:70
	AddressSanitizer:DEADLYSIGNAL
	=================================================================
	==14555==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000001dbc66a bp 0x7f772c079270 sp 0x7f772c0791c0 T3)
	==14555==The signal is caused by a WRITE memory access.
	==14555==Hint: address points to the zero page.
	SCARINESS: 10 (null-deref)
	#0 0x1dbc669 in mozilla::UniquePtr<js::detail::BumpChunk, JS::DeletePolicy<js::detail::BumpChunk> >::get() const mozilla-central/js/src/build_DBG.OBJ/dist/include/mozilla/UniquePtr.h:326:32
	#1 0x1dbc669 in mozilla::UniquePtr<js::detail::BumpChunk, JS::DeletePolicy<js::detail::BumpChunk> >::operator bool() const mozilla-central/js/src/build_DBG.OBJ/dist/include/mozilla/UniquePtr.h:324
	#2 0x1dbc669 in js::LifoAlloc::newChunkWithCapacity(unsigned long) mozilla-central/js/src/ds/LifoAlloc.cpp:94
	#3 0x1dbc98a in js::LifoAlloc::getOrCreateChunk(unsigned long) mozilla-central/js/src/ds/LifoAlloc.cpp:126:26
	#4 0x74d96c in js::LifoAlloc::allocImpl(unsigned long) mozilla-central/js/src/ds/LifoAlloc.h:498:14
	#5 0xeeef65 in js::LifoAlloc::allocInfallible(unsigned long) mozilla-central/js/src/ds/LifoAlloc.h:570:28
	#6 0xeeef65 in js::jit::TempAllocator::allocateInfallible(unsigned long) mozilla-central/js/src/jit/JitAllocPolicy.h:44
	#7 0x1468297 in js::jit::TempObject::operator new(unsigned long, js::jit::TempAllocator&) mozilla-central/js/src/jit/JitAllocPolicy.h:162:22
	#8 0x1468297 in js::jit::MPhi::New(js::jit::TempAllocator&, js::jit::MIRType) mozilla-central/js/src/jit/MIR.h:7825
	#9 0x1468297 in js::jit::ObjectMemoryView::mergeIntoSuccessorState(js::jit::MBasicBlock*, js::jit::MBasicBlock*, js::jit::MObjectState**) mozilla-central/js/src/jit/ScalarReplacement.cpp:459
	#10 0x14b7e86 in js::jit::EmulateStateOf<js::jit::ObjectMemoryView>::run(js::jit::ObjectMemoryView&) mozilla-central/js/src/jit/ScalarReplacement.cpp:89:23
	#11 0x1472500 in js::jit::ScalarReplacement(js::jit::MIRGenerator*, js::jit::MIRGraph&) mozilla-central/js/src/jit/ScalarReplacement.cpp:1424:36
	#12 0xf42932 in js::jit::OptimizeMIR(js::jit::MIRGenerator*) mozilla-central/js/src/jit/Ion.cpp:1548:14
	#13 0xf671e7 in js::jit::CompileBackEnd(js::jit::MIRGenerator*) mozilla-central/js/src/jit/Ion.cpp:1980:10
	#14 0x20f30dc in js::HelperThread::handleIonWorkload(js::AutoLockHelperThreadState&) mozilla-central/js/src/vm/HelperThreads.cpp:1907:39
	#15 0x20f0ff6 in js::HelperThread::threadLoop() mozilla-central/js/src/vm/HelperThreads.cpp:2296:13
	#16 0x20e66dc in js::HelperThread::ThreadMain(void*) mozilla-central/js/src/vm/HelperThreads.cpp:1816:38
	#17 0x211a362 in void js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) mozilla-central/js/src/threading/Thread.h:242:5
	#18 0x211a362 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) mozilla-central/js/src/threading/Thread.h:235
	#19 0x7f772facd6b9 in start_thread
	AddressSanitizer can not provide additional info.
	SUMMARY: AddressSanitizer: SEGV (/mnt/scratch0/clusterfuzz/slave-bot/builds/clusterfuzz-builds-no-engine_spidermonkey_6aad6e0d14f81d36f48dbd887aa56b38e87859f7/revisions/js+0x1dbc669)

Comment 1

[Alex Gaynor [:Alex_Gaynor]]

Attachment: clusterfuzz-testcase-minimized-5549761126989824.js

Ooops, forgot to attach the reproducer!

Comment 2

[Nicolas B. Pierron [:nbp]]

Attachment: Use the fallible allocator to allocate Phi for object properties.

The problem seen here, is that we are likely to fail after "inlining" the
properties on an object which has a large number of properties.

This bug went unnoticed until now because it requires to have a large number
of properties, which as far as I understand is not permitted by TI for
unboxed objects, and prevented for Arrays by checking the allocation size.

I guess that the issue seen here is related to the fact that we attempt to
inline a call object which has a large amount of variables (~100) which are
all captured by an inner function.

While we are supposed to ensure that we have enough ballast space in the
BlockState::Copy allocation, a large number of captured variables would
result to as many MPhi::New.  Also, the block in which these MPhi are
allocated for, should have at most 2 predecessors, otherwise the
reserveLength function would also ensure that we have enough ballast space.

This patch is using the fallible allocator of MPhi instead of the infallible
one. It does so for both mergeIntoSuccessorState instances (ObjectMemoryView
/ ArrayMemoryView).

In addition, this patch changes FixedList::init, used by MObjectState::Copy,
to use allocateArray instead of allocate, as this was duplicating the
allocator code.

Comment 3

[Ted Campbell [:tcampbell]]

Comment on attachment 8939845 [details] [diff] [review]
Use the fallible allocator to allocate Phi for object properties.

Review of attachment 8939845 [details] [diff] [review]:
-----------------------------------------------------------------

Great!

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a7b9b4a615cc
Use the fallible allocator to allocate Phi for object properties. r=tcampbell

Comment 5

[Bogdan Tara[:bogdan_tara | bogdant]]

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