The following testcase crashes on mozilla-central revision c0ba5835ca48 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --thread-count=2 --ion-extra-checks --ion-check-range-analysis --ion-eager): oomTest(() => (4294967295 >>> 45.1)({ thisprops: gc('' + oomTest + '') })); Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff5cc3700 (LWP 49201)] 0x0000000000c7d556 in allocInfallibleOrAssert (n=72, this=<optimized out>) at js/src/ds/LifoAlloc.h:281 #0 0x0000000000c7d556 in allocInfallibleOrAssert (n=72, this=<optimized out>) at js/src/ds/LifoAlloc.h:281 #1 allocateInfallible (bytes=72, this=<optimized out>) at js/src/jit/JitAllocPolicy.h:40 #2 operator new (alloc=..., nbytes=72) at js/src/jit/JitAllocPolicy.h:174 #3 js::jit::LiveRange::New (alloc=..., vreg=3, from=..., to=...) at js/src/jit/BacktrackingAllocator.h:274 #4 0x0000000000c6383a in js::jit::VirtualRegister::addInitialRange (this=0x7ffff69a2428, alloc=..., from=from@entry=..., to=to@entry=...) at js/src/jit/BacktrackingAllocator.cpp:299 #5 0x0000000000c674b8 in js::jit::BacktrackingAllocator::buildLivenessInfo (this=this@entry=0x7ffff5cc20e0) at js/src/jit/BacktrackingAllocator.cpp:699 #6 0x0000000000c78380 in js::jit::BacktrackingAllocator::go (this=this@entry=0x7ffff5cc20e0) at js/src/jit/BacktrackingAllocator.cpp:807 #7 0x0000000000679e63 in js::jit::GenerateLIR (mir=mir@entry=0x7ffff699b1c0) at js/src/jit/Ion.cpp:1941 #8 0x000000000067a133 in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff699b1c0) at js/src/jit/Ion.cpp:2011 #9 0x00000000009f79b4 in js::HelperThread::handleIonWorkload (this=this@entry=0x7ffff6933800) at js/src/vm/HelperThreads.cpp:1276 #10 0x00000000009f96c7 in js::HelperThread::threadLoop (this=0x7ffff6933800) at js/src/vm/HelperThreads.cpp:1603 #11 0x0000000000aaff71 in nspr::Thread::ThreadRoutine (arg=0x7ffff692e160) at js/src/vm/PosixNSPR.cpp:45 #12 0x00007ffff7bc4182 in start_thread (arg=0x7ffff5cc3700) at pthread_create.c:312 #13 0x00007ffff6cb3fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 rax 0x0 0 rbx 0x2 2 rcx 0x7ffff6ca53cd 140737333842893 rdx 0x0 0 rsi 0x7ffff6f7a9d0 140737336814032 rdi 0x7ffff6f791c0 140737336807872 rbp 0x7ffff5cc1a80 140737317182080 rsp 0x7ffff5cc1a60 140737317182048 r8 0x7ffff5cc3700 140737317189376 r9 0x6372732f736a2f6c 7165916604736876396 r10 0x7ffff5cc1820 140737317181472 r11 0x7ffff6c27960 140737333328224 r12 0xf 15 r13 0x3 3 r14 0x0 0 r15 0x0 0 rip 0xc7d556 <js::jit::LiveRange::New(js::jit::TempAllocator&, unsigned int, js::jit::CodePosition, js::jit::CodePosition)+150> => 0xc7d556 <js::jit::LiveRange::New(js::jit::TempAllocator&, unsigned int, js::jit::CodePosition, js::jit::CodePosition)+150>: movl $0x119,0x0 0xc7d561 <js::jit::LiveRange::New(js::jit::TempAllocator&, unsigned int, js::jit::CodePosition, js::jit::CodePosition)+161>: callq 0x4a3830 <abort()>

JSBugMon: Bisection requested, result: === Treeherder Build Bisection Results by autoBisect === The "good" changeset has the timestamp "20151027074027" and the hash "5430b2dba98b2a39ccdfd3700131f780a27be17c". The "bad" changeset has the timestamp "20151027075125" and the hash "fbf7d94986bb51bb53bdfdfd57d29dcc62f31ae4". Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5430b2dba98b2a39ccdfd3700131f780a27be17c&tochange=fbf7d94986bb51bb53bdfdfd57d29dcc62f31ae4

Nicolas, is bug 991249 a likely regressor?

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #2) > Nicolas, is bug 991249 a likely regressor? No, this is just the patch which made these OOM testable.

Is this then related to bug 1244828?

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #4) > Is this then related to bug 1244828? No, this one is under the BacktrackingAllocator, as opposed to the TypeAnalysis. Still this should be a blocker of Bug 1244824.

LiveRange allocations are not happening at every loop iterations, and are dependent on the number of virtual register which is somewhat a function of the number of instructions. Thus we cannot consider this allocation as being infallible. Hopefulle (git grep -A 3 LiveRange::New) all allocations are already guarded.

Comment on attachment 8715302 [details] [diff] [review] Ensure enough ballast space in LiveRange::New. Review of attachment 8715302 [details] [diff] [review]: ----------------------------------------------------------------- The fix in bug 1245154 is better

Comment on attachment 8715302 [details] [diff] [review] Ensure enough ballast space in LiveRange::New. Review of attachment 8715302 [details] [diff] [review]: ----------------------------------------------------------------- Woops. Going too fast. Can you create FallibleNew and make sure all uses now use this new variant? (Just like in bug 1245154)

I had to back this out for breaking asm tests in mochitest-1: https://treeherder.mozilla.org/logviewer.html#?job_id=21287226&repo=mozilla-inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/7131c65c0d4a