1238694 - Crash [@ AutoWritableJitCode] or Crash [@ js::jit::Linker::newCode<(js::AllowGC)1>] or Crash [@ Instruction] or Crash [@ js::jit::JitCode::copyFrom]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 6020a4cb41a7 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-simulator=arm --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-eager --arm-asm-nop-fill=1 --arm-sim-icache-checks):

var lfcode = new Array();
lfcode.push(`
function testLambdaCtor() {
    var a = [];
    for (var x = 0; x < 9; +x) {
        var f = function(){ "use asm"; function x() {} return x };
        a[a.length] = new f;
    }
    assertEq( ... each  => function x(x) {
      return x.f
    });
    return a[8].__proto__ === f.prototype;
}
assertEq(testLambdaCtor(), true);
`);
loadFile(lfcode.shift());
loadFile(lfcode.shift());
function loadFile(lfVarx) {
  try {
    evaluate(lfVarx); 
  } catch(exc1) {}
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0841c583 in AutoWritableJitCode (size=<optimized out>, addr=<optimized out>, rt=<optimized out>, this=<synthetic pointer>) at js/src/jit/JitCompartment.h:556
#0  0x0841c583 in AutoWritableJitCode (size=<optimized out>, addr=<optimized out>, rt=<optimized out>, this=<synthetic pointer>) at js/src/jit/JitCompartment.h:556
#1  AutoWritableJitCode (size=<optimized out>, addr=<optimized out>, this=<synthetic pointer>) at js/src/jit/JitCompartment.h:559
#2  emplace<unsigned char*&, unsigned int&> (this=<synthetic pointer>) at js/src/debugarmsim/dist/include/mozilla/Maybe.h:386
#3  newCode<(js::AllowGC)1> (hasPatchableBackedges=false, kind=js::jit::BASELINE_CODE, cx=0xf7a78020, this=<synthetic pointer>) at js/src/jit/Linker.h:75
#4  js::jit::ICStubCompiler::getStubCode (this=this@entry=0xffffbdf0) at js/src/jit/SharedIC.cpp:744
#5  0x0826b57e in js::jit::ICCallScriptedCompiler::getStub (this=0xffffbdf0, space=0xf7aa4408) at js/src/jit/BaselineIC.h:2646
#6  0x0824f297 in js::jit::TryAttachCallStub (cx=cx@entry=0xf7a78020, stub=0xf5567450, script=script@entry=..., pc=pc@entry=0xf7a89d39 ":", op=op@entry=JSOP_CALL, argc=argc@entry=1, vp=vp@entry=0xf59ffec8, constructing=constructing@entry=false, isSpread=isSpread@entry=false, createSingleton=createSingleton@entry=false, handled=handled@entry=0xffffbf00) at js/src/jit/BaselineIC.cpp:5953
#7  0x082502f3 in js::jit::DoCallFallback (cx=cx@entry=0xf7a78020, frame=frame@entry=0xf59fff08, stub_=stub_@entry=0xf5567450, argc=argc@entry=1, vp=vp@entry=0xf59ffec8, res=res@entry=...) at js/src/jit/BaselineIC.cpp:6141
#8  0x084f697e in js::jit::Simulator::softwareInterrupt (this=0xf7a77000, instr=0xf55c2234) at js/src/jit/arm/Simulator-arm.cpp:2360
#9  0x084f6c66 in js::jit::Simulator::decodeType7 (this=0xf7a77000, instr=0xf55c2234) at js/src/jit/arm/Simulator-arm.cpp:3482
#10 0x084f4c25 in js::jit::Simulator::instructionDecode (this=this@entry=0xf7a77000, instr=instr@entry=0xf55c2234) at js/src/jit/arm/Simulator-arm.cpp:4404
#11 0x084f8a24 in execute<false> (this=0xf7a77000) at js/src/jit/arm/Simulator-arm.cpp:4459
[...]
#24 Shell (envp=<optimized out>, op=0xffffcc70, cx=0xf7a78020) at js/src/shell/js.cpp:6561
#25 main (argc=7, argv=0xffffcdc4, envp=0xffffcde4) at js/src/shell/js.cpp:6918
eax	0x0	0
ebx	0x980943c	159421500
ecx	0xf7e3b88c	-136071028
edx	0x0	0
esi	0xf7a78020	-140017632
edi	0xf5768178	-176782984
ebp	0xffffbcc8	4294950088
esp	0xffffb510	4294948112
eip	0x841c583 <js::jit::ICStubCompiler::getStubCode()+6707>
=> 0x841c583 <js::jit::ICStubCompiler::getStubCode()+6707>:	movl   $0x22c,0x0
   0x841c58d <js::jit::ICStubCompiler::getStubCode()+6717>:	call   0x80f8c10 <abort()>


This test crashed in multiple ways, including a crash with a random memory address. Marking s-s until investigated. Unfortunately, the test is also intermittent, but reproduces most of the time.

Comment 1

[Terrence Cole [:terrence]]

Jan, I guess AutoWritableJitCode is in your ambit?

Comment 2

[Fuzzing Team]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 7104d650a97d).

Comment 3

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

__proto__.valueOf = function() {
    "use asm";
    function f() {};
    return f;
}
gcslice(1);
function g(x) {
    Math > x;
}
function h(f) {
    for (var i = 0; i < 99999; i++) {
        try {
            f();
        } catch (e) {}
    }
}
h(g);

$ /home/ubuntu/shell-cache/js-64-linux-aa90f482e16d/js-64-linux-aa90f482e16d --fuzzing-safe --ion-offthread-compile=off --ion-eager testcase.js
uncaught exception: out of memory
(Unable to print stack trace)

$ /home/ubuntu/shell-cache/js-64-linux-aa90f482e16d/js-64-linux-aa90f482e16d --fuzzing-safe --ion-offthread-compile=off --ion-eager testcase.js
Segmentation fault (core dumped)


AR=ar sh /home/ubuntu/trees/mozilla-central/js/src/configure --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

python -u ~/funfuzz/js/compileShell.py -b "" -r aa90f482e16d


I agree that this testcase is intermittent.

Comment 4

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

Tested with the testcase in comment 3 on Linux.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/a0dbf1fe665f
user:        Jan de Mooij
date:        Mon Dec 28 21:05:50 2015 +0100
summary:     Bug 1215479 - Turn on W^X JIT code by default. r=luke

Jan, is bug 1215479 a likely regressor?

Comment 5

[Andrew McCreight [:mccr8]]

I'm going to mark this sec-high conservatively, given that it has weird crashy behavior.

Comment 6

[Jan de Mooij [:jandem]]

Attachment: Patch

On Linux, we can't allocate more than ~32k wasm modules per process before running into kernel limits. The patch limits this to 16384, to avoid crashing in the AutoWritableJitCode constructor.

Comment 7

[Jan de Mooij [:jandem]]

Not security-sensitive; we're just hitting a MOZ_CRASH (in AutoWritableJitCode).

Comment 8

[Luke Wagner [:luke]]

Comment on attachment 8729513 [details] [diff] [review]
Patch

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

Thanks!

Comment 9

[Luke Wagner [:luke]]

Comment on attachment 8729513 [details] [diff] [review]
Patch

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

::: js/src/asmjs/WasmModule.cpp
@@ +75,2 @@
>      if (!p)
>          ReportOutOfMemory(cx);

Oh wait, we need to worry about decrementing wasmCodeAllocations in the failure case.

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4e3b9f88ef1a

Comment 12

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

https://hg.mozilla.org/mozilla-central/rev/4e3b9f88ef1a

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

This has some crashes in beta 46, spiking in beta 8: https://crash-stats.mozilla.com/report/list?signature=js%3A%3Ajit%3A%3AJitCode%3A%3AcopyFrom

While it would be very late in beta, might this be good to uplift? Do you think it would be more risk than it's worth?

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Hmm. But 0 crashes in beta 9. That's odd.

Comment 15

[Jan de Mooij [:jandem]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #13)
> While it would be very late in beta, might this be good to uplift? Do you
> think it would be more risk than it's worth?

It's very unlikely that this patch will help with those crashes. You need to create thousands of asm.js modules, without GC'ing any of them, and this bug may only affect Linux while the crashes are on Windows IIRC.

I'll look at these crashes (bug 1261300) today.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Thanks Jan. Marking this wontfix for 46 then.

Comment 17

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

Jan, is it ok if we get this on to Aurora as well?

Comment 18

[Jan de Mooij [:jandem]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #17)
> Jan, is it ok if we get this on to Aurora as well?

Would that help fuzzing? It's an edge case that's really unlikely to show up in the wild, so unless there's a good reason I'd prefer letting it ride the trains.

Comment 19

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

(In reply to Jan de Mooij [:jandem] from comment #18)
> Would that help fuzzing? It's an edge case that's really unlikely to show up
> in the wild, so unless there's a good reason I'd prefer letting it ride the
> trains.

No, it does not affect much. Let's leave it to the trains then.

Comment 20

[Eric Faust [:efaust]]

We've agreed to let this ride. Marking 47 as wontfix.