Christian Holler (:decoder) Reporter
	Description • 8 years ago

The following testcase crashes on mozilla-central revision 701868bfddcb (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug --enable-optimize, run with --fuzzing-safe --ion-aa=flow-sensitive --ion-eager):

See attachment.


Backtrace:

 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff48fb700 (LWP 18113)]
js::LifoAlloc::getOrCreateChunk (this=this@entry=0x7ffff0338440, n=n@entry=56) at js/src/ds/LifoAlloc.cpp:105
#0  js::LifoAlloc::getOrCreateChunk (this=this@entry=0x7ffff0338440, n=n@entry=56) at js/src/ds/LifoAlloc.cpp:105
#1  0x00000000005f6d03 in js::LifoAlloc::allocImpl (n=56, this=0x7ffff0338440) at js/src/ds/LifoAlloc.h:225
#2  js::LifoAlloc::allocInfallible (this=0x7ffff0338440, n=56) at js/src/ds/LifoAlloc.h:291
#3  0x000000000064102c in js::jit::TempAllocator::allocateInfallible (bytes=56, this=<optimized out>) at js/src/jit/JitAllocPolicy.h:44
#4  js::jit::TempObject::operator new (alloc=..., nbytes=56) at js/src/jit/JitAllocPolicy.h:162
#5  js::jit::FlowAliasAnalysis::saveStoreDependency (this=this@entry=0x7ffff48faa70, ins=ins@entry=0x7ffff0577450, prevStores=...) at js/src/jit/FlowAliasAnalysis.cpp:818
#6  0x000000000065747f in js::jit::FlowAliasAnalysis::processStore (this=this@entry=0x7ffff48faa70, blockInfo=..., store=store@entry=0x7ffff0577450) at js/src/jit/FlowAliasAnalysis.cpp:518
#7  0x000000000065963f in js::jit::FlowAliasAnalysis::analyze (this=<optimized out>) at js/src/jit/FlowAliasAnalysis.cpp:487
#8  0x000000000065a745 in js::jit::OptimizeMIR (mir=mir@entry=0x7ffff05021c8) at js/src/jit/Ion.cpp:1698
#9  0x000000000065b9d6 in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff05021c8) at js/src/jit/Ion.cpp:2067
#10 0x0000000000b0ebbe in js::HelperThread::handleIonWorkload (this=this@entry=0x7ffff6948460, locked=...) at js/src/vm/HelperThreads.cpp:1511
#11 0x0000000000b0f835 in js::HelperThread::threadLoop (this=this@entry=0x7ffff6948460) at js/src/vm/HelperThreads.cpp:1874
#12 0x0000000000b0fb75 in js::HelperThread::ThreadMain (arg=0x7ffff6948460) at js/src/vm/HelperThreads.cpp:1407
#13 0x0000000000b1a462 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul> (this=0x7ffff69200a0) at js/src/threading/Thread.h:234
#14 js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start (aPack=0x7ffff69200a0) at js/src/threading/Thread.h:227
#15 0x00007ffff7bc16fa in start_thread (arg=0x7ffff48fb700) at pthread_create.c:333
#16 0x00007ffff6c38b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
rax	0x204e520	33875232
rbx	0x1217988	18971016
rcx	0x7ffff6c28a2d	140737333332525
rdx	0x0	0
rsi	0x7ffff6ef7770	140737336276848
rdi	0x7ffff6ef6540	140737336272192
rbp	0x7ffff48fa6f0	140737296443120
rsp	0x7ffff48fa630	140737296442928
r8	0x7ffff6ef7770	140737336276848
r9	0x7ffff48fb700	140737296447232
r10	0x58	88
r11	0x7ffff6b9f750	140737332770640
r12	0x7ffff0580ff0	140737225691120
r13	0x7ffff0338440	140737223296064
r14	0x38	56
r15	0x0	0
rip	0x825030 <js::LifoAlloc::getOrCreateChunk(unsigned long)+944>
=> 0x825030 <js::LifoAlloc::getOrCreateChunk(unsigned long)+944>:	movl   $0x0,0x0
   0x82503b <js::LifoAlloc::getOrCreateChunk(unsigned long)+955>:	ud2    


This one looks significantly different to bug 1329651 that I just filed.

	Justin [:JW_SoftvisionQA]
	Comment 2 • 8 years ago

Sorry I have too many bugs open at once. this was an accident

	Christian Holler (:decoder) Reporter
	Comment 3 • 8 years ago

This bug is now triggering very often, marking as fuzzblocker.

	Nicolas B. Pierron [:nbp] Assignee
	Comment 4 • 8 years ago

I honestly did not beleived this line was the faulty one, but it was.

The reason I did not beleive it is that we are using vectors in which we
append data into. When we append into a vector, we run ensureBallast right
after the allocation.

The reason is that the StoreDependency's vector has a reserve space of 1,
which means that the first append could be an infallible append and the init
function could be infallible. Then later, other vectors might not be resized
because we already have large allocations.

So, this new allocation can be the only looping allocation, thus making it
fallible solves the issue.

Thanks to this assertion, even if the code was written as being checked
against allocation failures, already, the allocator being used was the
infallible one.

	Hannes Verschore [:h4writer]
	Comment 5 • 8 years ago

Comment on attachment 8828751 [details] [diff] [review]
Use fallible allocator in FlowAliasAnalysis::saveStoreDependency.

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

Good find!

	Pulsebot
	Comment 6 • 8 years ago

Pushed by npierron@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ae8caa5d668a
Use fallible allocator in FlowAliasAnalysis::saveStoreDependency. r=h4writer

	Fuzzing Team
	Comment 7 • 8 years ago

JSBugMon: Cannot process bug: Error: Unsupported branch "53 Branch" required by bug

	Carsten Book [:Tomcat]
	Comment 8 • 8 years ago
bugherder

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

	Ryan VanderMeulen [:RyanVM]
	Comment 9 • 8 years ago

Actually, looks like 52 might be affected? Please nominate this for Aurora approval if that's indeed the case.

	Nicolas B. Pierron [:nbp] Assignee
	Comment 10 • 8 years ago

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)
> Actually, looks like 52 might be affected? Please nominate this for Aurora
> approval if that's indeed the case.

This code is currently disabled, and only used by fuzzers with the  --ion-aa=flow-sensitive  JS Shell flag.  I don't think this would be necessary to backport unless fuzzers are also blocked for the same reason on older branches.