1324521 - Hit MOZ_CRASH(Unexpected instruction) at jit/BaselineInspector.cpp:991 or Crash [@ GetCacheIRExpectedInputType]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 863c2b61bd27 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-debug --enable-optimize, run with --fuzzing-safe):

function f() {
    var args = arguments
    for (i = 0;;) args[i];
};
f();



Backtrace:

 received signal SIGSEGV, Segmentation fault.
#0  GetCacheIRExpectedInputType (stub=0x7ffff03f8088) at js/src/jit/BaselineInspector.cpp:991
#1  js::jit::BaselineInspector::expectedPropertyAccessInputType (this=<optimized out>, pc=<optimized out>) at js/src/jit/BaselineInspector.cpp:1020
#2  0x00000000005a4384 in js::jit::IonBuilder::maybeUnboxForPropertyAccess (this=this@entry=0x7ffff04cd228, def=def@entry=0x7ffff04d0208) at js/src/jit/IonBuilder.cpp:9873
#3  0x00000000005eaee3 in js::jit::IonBuilder::maybeUnboxForPropertyAccess (def=0x7ffff04d0208, this=0x7ffff04cd228) at js/src/jit/IonBuilder.cpp:7428
#4  js::jit::IonBuilder::jsop_getelem (this=0x7ffff04cd228) at js/src/jit/IonBuilder.cpp:7426
#5  0x00000000005edfdc in js::jit::IonBuilder::inspectOpcode (this=this@entry=0x7ffff04cd228, op=op@entry=JSOP_GETELEM) at js/src/jit/IonBuilder.cpp:2142
#6  0x00000000005eeecc in js::jit::IonBuilder::visitBlock (this=this@entry=0x7ffff04cd228, cfgblock=cfgblock@entry=0x7ffff03f9088, mblock=<optimized out>) at js/src/jit/IonBuilder.cpp:1548
#7  0x00000000005ef1eb in js::jit::IonBuilder::traverseBytecode (this=0x7ffff04cd228) at js/src/jit/IonBuilder.cpp:1463
#8  0x00000000005ef6d6 in js::jit::IonBuilder::build (this=0x7ffff04cd228) at js/src/jit/IonBuilder.cpp:839
#9  0x000000000042c0ac in js::jit::IonCompile (cx=cx@entry=0x7ffff695f000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x7fffffffcac8, osrPc=osrPc@entry=0x7ffff03f60b5 "\343\201V", recompile=<optimized out>, optimizationLevel=<optimized out>) at js/src/jit/Ion.cpp:2236
#10 0x00000000005fa2ea in js::jit::Compile (cx=cx@entry=0x7ffff695f000, script=script@entry=..., osrFrame=osrFrame@entry=0x7fffffffcac8, osrPc=osrPc@entry=0x7ffff03f60b5 "\343\201V", forceRecompile=<optimized out>) at js/src/jit/Ion.cpp:2488
#11 0x00000000005fa8ac in BaselineCanEnterAtBranch (pc=0x7ffff03f60b5 "\343\201V", osrFrame=0x7fffffffcac8, script=..., cx=0x7ffff695f000) at js/src/jit/Ion.cpp:2679
#12 js::jit::IonCompileScriptForBaseline (cx=cx@entry=0x7ffff695f000, frame=frame@entry=0x7fffffffcac8, pc=pc@entry=0x7ffff03f60b5 "\343\201V") at js/src/jit/Ion.cpp:2737
#13 0x0000000000b784fc in js::jit::DoWarmUpCounterFallbackOSR (cx=0x7ffff695f000, frame=0x7fffffffcac8, stub=<optimized out>, infoPtr=0x7fffffffca90) at js/src/jit/BaselineIC.cpp:144
#14 0x00007ffff7e3d3e9 in ?? ()
[...]
#25 0x0000000000000000 in ?? ()
rax	0x1ba4340	28984128
rbx	0xe0f900	14743808
rcx	0x28	40
rdx	0x7ffff03f4541	140737224066369
rsi	0x7ffff03f4520	140737224066336
rdi	0x7fffffffc550	140737488340304
rbp	0x7fffffffc590	140737488340368
rsp	0x7fffffffc550	140737488340304
r8	0xb0	176
r9	0xa	10
r10	0x90	144
r11	0x18	24
r12	0x7ffff03f8088	140737224081544
r13	0x7fffffffc550	140737488340304
r14	0xe60bc8	15076296
r15	0x7ffff03fc580	140737224099200
rip	0xb7da3b <js::jit::BaselineInspector::expectedPropertyAccessInputType(unsigned char*)+267>
=> 0xb7da3b <js::jit::BaselineInspector::expectedPropertyAccessInputType(unsigned char*)+267>:	movl   $0x0,0x0
   0xb7da46 <js::jit::BaselineInspector::expectedPropertyAccessInputType(unsigned char*)+278>:	ud2    


Marking s-s because unexpected instruction doesn't sound good to me.

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20161120111822" and the hash "3421c306d8cf844b149594517340275173a5460f".
The "bad" changeset has the timestamp "20161219102923" and the hash "c141ad08e219041aa5505fe925d086e3a93df0b9".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3421c306d8cf844b149594517340275173a5460f&tochange=c141ad08e219041aa5505fe925d086e3a93df0b9

Comment 2

[Sean Stangl [:sstangl]]

Setting needinfo?jandem since the crash is in GetCacheIRExpectedInputType().

Comment 3

[Jan de Mooij [:jandem]]

Not s-s, just a MOZ_CRASH for a case we don't handle.

Comment 4

[Jan de Mooij [:jandem]]

Attachment: Patch

The easy two-line fix is to add CacheOp::GuardMagicValue to GetCacheIRExpectedInputType in BaselineInspector.cpp

However, I think it's nicer to restructure IonBuilder::jsop_getelem to handle lazy arguments first, so this case can't come up.

I also fixed the code to avoid aborts when we're in analysis mode, similar to what we do in IonBuilder::jsop_getprop.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/74717635e168
Restructure IonBuilder::jsop_getelem to handle lazy arguments first. r=nbp

Comment 6

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

https://hg.mozilla.org/mozilla-central/rev/74717635e168