1145785 - Crash [@ __memset_sse2_rep] with ArrayBuffer

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision cf1060d8ce9f (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --enable-arm-simulator --disable-debug, run with --thread-count=2 --ion-check-range-analysis --ion-offthread-compile=off --arm-sim-icache-checks --ion-eager):

this.loadFile("function testcase() { try { testcase(new ArrayBuffer(0x200000))() } catch (e) {} } testcase();");
Object.defineProperty(this, "testutils", {});
function loadFile(lfVarx) {
  evaluate(lfVarx, { noScriptRval : true, compileAndGo : true }); 
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
__memset_sse2_rep () at ../sysdeps/i386/i686/multiarch/memset-sse2-rep.S:183
#0  __memset_sse2_rep () at ../sysdeps/i386/i686/multiarch/memset-sse2-rep.S:183
#1  0x08485bf0 in FlushOnePageLocked (size=4, start=<optimized out>, i_cache=...) at js/src/jit/arm/Simulator-arm.cpp:978
#2  FlushICacheLocked (size=<optimized out>, start_addr=0xfca80fe4, i_cache=...) at js/src/jit/arm/Simulator-arm.cpp:999
#3  Redirection (sim=0x9397598, type=js::jit::Args_General3, nativeFunction=0x80b88e0 <js::obj_defineProperty(JSContext*, unsigned int, JS::Value*)>, this=0xfca80fe0) at js/src/jit/arm/Simulator-arm.cpp:1166
#4  Get (type=type@entry=js::jit::Args_General3, nativeFunction=0x80b88e0 <js::obj_defineProperty(JSContext*, unsigned int, JS::Value*)>) at js/src/jit/arm/Simulator-arm.cpp:1194
#5  js::jit::Simulator::RedirectNativeFunction (nativeFunction=0x80b88e0 <js::obj_defineProperty(JSContext*, unsigned int, JS::Value*)>, type=type@entry=js::jit::Args_General3) at js/src/jit/arm/Simulator-arm.cpp:1226
#6  0x08327cde in ICCall_Native (pcOffset=45, templateObject=<optimized out>, callee=0xf60473e0, firstMonitorStub=<optimized out>, stubCode=<optimized out>, this=0xf8881ad8) at js/src/jit/BaselineIC.cpp:12014
#7  allocate<js::jit::ICCall_Native, js::jit::JitCode*&, js::jit::ICStub*&, JS::Rooted<JSFunction*>&, JS::Rooted<JSObject*>&, unsigned int&> (this=0x9452120) at js/src/jit/JitCompartment.h:84
#8  New<js::jit::ICCall_Native, js::jit::ICStub*&, JS::Rooted<JSFunction*>&, JS::Rooted<JSObject*>&, unsigned int&> (code=<optimized out>, space=0x9452120) at js/src/jit/BaselineIC.h:639
#9  js::jit::ICCall_Native::Compiler::getStub (this=this@entry=0xffffc1d0, space=0x9452120) at js/src/jit/BaselineIC.h:5498
#10 0x0830a541 in js::jit::TryAttachCallStub (cx=cx@entry=0x9398228, stub=stub@entry=0x9451f98, script=..., script@entry=..., pc=pc@entry=0x94529e6 ":", op=op@entry=JSOP_CALL, argc=argc@entry=3, vp=vp@entry=0xf5efeea0, constructing=constructing@entry=false, isSpread=isSpread@entry=false, createSingleton=false, handled=handled@entry=0xffffc270) at js/src/jit/BaselineIC.cpp:9440
#11 0x0830bace in js::jit::DoCallFallback (cx=0x9398228, frame=frame@entry=0xf5efef00, stub_=stub_@entry=0x9451f98, argc=argc@entry=3, vp=vp@entry=0xf5efeea0, res=res@entry=...) at js/src/jit/BaselineIC.cpp:9549
#12 0x084ac351 in js::jit::Simulator::softwareInterrupt (this=0x9397598, instr=0x93d2bb4) at js/src/jit/arm/Simulator-arm.cpp:2173
#13 0x084ac50d in js::jit::Simulator::decodeType7 (this=this@entry=0x9397598, instr=instr@entry=0x93d2bb4) at js/src/jit/arm/Simulator-arm.cpp:3259
#14 0x084ac84c in js::jit::Simulator::instructionDecode (this=this@entry=0x9397598, instr=instr@entry=0x93d2bb4) at js/src/jit/arm/Simulator-arm.cpp:4178
#15 0x084aefc4 in execute<false> (this=0x9397598) at js/src/jit/arm/Simulator-arm.cpp:4233
#16 js::jit::Simulator::callInternal (this=this@entry=0x9397598, entry=entry@entry=0xf7fc8828 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>) at js/src/jit/arm/Simulator-arm.cpp:4321
#17 0x084af1d6 in js::jit::Simulator::call (this=<optimized out>, entry=entry@entry=0xf7fc8828 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>, argument_count=<optimized out>, argument_count@entry=8) at js/src/jit/arm/Simulator-arm.cpp:4404
#18 0x082965aa in EnterBaseline (cx=cx@entry=0x9398228, data=...) at js/src/jit/BaselineJIT.cpp:122
#19 0x082c35f9 in js::jit::EnterBaselineMethod (cx=cx@entry=0x9398228, state=...) at js/src/jit/BaselineJIT.cpp:154
#20 0x08192c15 in js::RunScript (cx=cx@entry=0x9398228, state=...) at js/src/vm/Interpreter.cpp:442
#21 0x0819a742 in js::ExecuteKernel (cx=cx@entry=0x9398228, script=script@entry=..., scopeChainArg=..., thisv=..., type=type@entry=js::EXECUTE_GLOBAL, evalInFrame=evalInFrame@entry=..., result=result@entry=0x0) at js/src/vm/Interpreter.cpp:655
#22 0x0819aa45 in js::Execute (cx=cx@entry=0x9398228, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0x0) at js/src/vm/Interpreter.cpp:692
#23 0x084cc350 in ExecuteScript (cx=cx@entry=0x9398228, obj=..., scriptArg=scriptArg@entry=..., rval=rval@entry=0x0) at js/src/jsapi.cpp:4101
#24 0x084cc3f1 in JS_ExecuteScript (cx=cx@entry=0x9398228, scriptArg=scriptArg@entry=...) at js/src/jsapi.cpp:4123
#25 0x0804b64c in RunFile (compileOnly=false, file=0x93e5ed0, filename=<optimized out>, cx=0x9398228) at js/src/shell/js.cpp:466
#26 Process (cx=cx@entry=0x9398228, filename=<optimized out>, forceTTY=forceTTY@entry=false) at js/src/shell/js.cpp:597
#27 0x080595e0 in ProcessArgs (op=0xffffcb20, cx=<optimized out>) at js/src/shell/js.cpp:5743
#28 Shell (envp=<optimized out>, op=0xffffcb20, cx=<optimized out>) at js/src/shell/js.cpp:6009
#29 main (argc=7, argv=0xffffccb4, envp=0xffffccd4) at js/src/shell/js.cpp:6351
eax	0x1010101	16843009
ebx	0xf7dbb3b5	-136596555
ecx	0x1	1
edx	0x13fa	5114
esi	0x3f9	1017
edi	0xfca80fe4	-56094748
ebp	0x9397598	154760600
esp	0xffffc098	4294951064
eip	0xf7dbb3b5 <__memset_sse2_rep+117>
=> 0xf7dbb3b5 <__memset_sse2_rep+117>:	mov    %al,-0x1(%edx)
   0xf7dbb3b8 <__memset_sse2_rep+120>:	mov    0x8(%esp),%eax


S-s due to bad memory access.

Comment 1

[Daniel Veditz [:dveditz]]

This could even be a Simulator bug. Any chance to check this on real ARM hardware?

Comment 2

[Christian Holler (:decoder)]

Why should particular bug be a simulator bug? And no, I don't have any ARM hardware, typically JS devs check if those bugs are real or not and we haven't had pure simulator bugs for quite a while. Waiting for the bisection to happen now.

Comment 3

[Christian Holler (:decoder)]

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

Comment 4

[Christian Holler (:decoder)]

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

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to Christian Holler (:decoder) from comment #2)
> Why should particular bug be a simulator bug?

Because this one is crashing in a Simulator function, and I don't think ARM has "sse2" (though maybe it does these days).

Comment 6

[Andrew McCreight [:mccr8]]

Is there some way we can figure out what the fix was for this so we can know if it was really fixed or if it is just a flakey test?

Comment 7

[Christian Holler (:decoder)]

(In reply to Daniel Veditz [:dveditz] from comment #5)
> (In reply to Christian Holler (:decoder) from comment #2)
> > Why should particular bug be a simulator bug?
> 
> Because this one is crashing in a Simulator function, and I don't think ARM
> has "sse2" (though maybe it does these days).

The sse2 has nothing to do with the bug itself. It occurs in the stack trace because a memset is out-of-bounds and since the emulating platform has sse2, it's using an SSE2-optimized version of memset. The fact that the crash is in a simulator function is actually not special at all. Since it's kind of an emulator, we *must* crash in such a function (where else?). I suggest that the JS developer(s) responsible for ARM just look at the bug and figure out what is/was wrong. They can also tell best, if this bug is really fixed or not.

I'm putting a needinfo for jandem here, maybe he can proxy this to the right person.

Comment 8

[Andrew McCreight [:mccr8]]

ArrayBuffer is involved.  Maybe you could look at this, sfink?  Thanks.

Comment 9

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

Tracking for Firefox 39 since it's marked as sec-critical.

Comment 10

[Jan de Mooij [:jandem]]

Attachment: Patch

I can't repro this but this looks like an OOM in the simulator's --arm-sim-icache-checks feature.

Comment 11

[Jan de Mooij [:jandem]]

Simulator is NPOTB.

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fceaf20d128c

Comment 13

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

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