1243397 - Assertion failure: result ([OOM] Is it really infallible?), at js/src/ds/LifoAlloc.h:281 with BacktrackingAllocator involved

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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

Comment 1

[Fuzzing Team]

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

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Nicolas, is bug 991249 a likely regressor?

Comment 3

[Nicolas B. Pierron [:nbp]]

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

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Is this then related to bug 1244828?

Comment 5

[Nicolas B. Pierron [:nbp]]

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

Comment 6

[Nicolas B. Pierron [:nbp]]

Attachment: Ensure enough ballast space in LiveRange::New.

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 7

[Hannes Verschore [:h4writer]]

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 8

[Hannes Verschore [:h4writer]]

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)

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/092754992cef

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/08c473408dcc

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/08c473408dcc