Closed Bug 1238694 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: JavaScript Engine, defect, critical)

ARM
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- fixed

People

(Reporter: decoder, Assigned: jandem)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression, testcase, Whiteboard: [jsbugmon:ignore])

Crash Data

Attachments

(1 file)

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.
Jan, I guess AutoWritableJitCode is in your ambit?
Flags: needinfo?(jdemooij)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update,bisect,ignore]
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 7104d650a97d).
__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.
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?
Blocks: 1215479
Whiteboard: [jsbugmon:update,bisect,ignore] → [jsbugmon:ignore]
Crash Signature: [@ AutoWritableJitCode][@ js::jit::Linker::newCode<(js::AllowGC)1>][@ Instruction] → [@ AutoWritableJitCode] [@ js::jit::Linker::newCode<(js::AllowGC)1>] [@ Instruction] [@ js::jit::JitCode::copyFrom]
Summary: Crash [@ AutoWritableJitCode] or Crash [@ js::jit::Linker::newCode<(js::AllowGC)1>] or Crash [@ Instruction] → Crash [@ AutoWritableJitCode] or Crash [@ js::jit::Linker::newCode<(js::AllowGC)1>] or Crash [@ Instruction] or Crash [@ js::jit::JitCode::copyFrom]
I'm going to mark this sec-high conservatively, given that it has weird crashy behavior.
Keywords: sec-high
Attached patch PatchSplinter Review
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.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Flags: needinfo?(jdemooij)
Attachment #8729513 - Flags: review?(luke)
Not security-sensitive; we're just hitting a MOZ_CRASH (in AutoWritableJitCode).
Group: javascript-core-security
Keywords: sec-high
Comment on attachment 8729513 [details] [diff] [review]
Patch

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

Thanks!
Attachment #8729513 - Flags: review?(luke) → review+
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.
Duplicate of this bug: 1238422
https://hg.mozilla.org/mozilla-central/rev/4e3b9f88ef1a
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
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?
Flags: needinfo?(jdemooij)
Hmm. But 0 crashes in beta 9. That's odd.
(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.
Flags: needinfo?(jdemooij)
Thanks Jan. Marking this wontfix for 46 then.
Jan, is it ok if we get this on to Aurora as well?
Flags: needinfo?(jdemooij)
(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.
(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.
Flags: needinfo?(jdemooij)
We've agreed to let this ride. Marking 47 as wontfix.
You need to log in before you can comment on or make changes to this bug.