1151323 - Assertion failure: output.type() == MIRTypeFromValueType(type), at js/src/jit/MacroAssembler.cpp:808 with --unboxed-objects

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 90adc073cbc6 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-debug, run with --unboxed-objects --ion-offthread-compile=off --ion-eager):

function map_test(cases) {
    for (var i = 0; i < cases.length; i++) {
        var expected = cases[i].expected;
    }
}
map_test([{ input: 8, expected: 1114369}, { input: -1, expected: 0}]);
map_test([{ expected: 16777215}, { expected: 4294967241 }]);



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0862dda4 in js::jit::MacroAssembler::loadUnboxedProperty<js::jit::Address> (this=0xf7ab1030, address=..., type=JSVAL_TYPE_INT32, output=...) at js/src/jit/MacroAssembler.cpp:808
#0  0x0862dda4 in js::jit::MacroAssembler::loadUnboxedProperty<js::jit::Address> (this=0xf7ab1030, address=..., type=JSVAL_TYPE_INT32, output=...) at js/src/jit/MacroAssembler.cpp:808
#1  0x08481dfa in js::jit::CodeGenerator::emitGetPropertyPolymorphic (this=this@entry=0xf7ab1000, ins=ins@entry=0xf7aa6110, obj=obj@entry=..., scratch=..., output=...) at js/src/jit/CodeGenerator.cpp:2309
#2  0x084823a9 in js::jit::CodeGenerator::visitGetPropertyPolymorphicT (this=0xf7ab1000, ins=0xf7aa6110) at js/src/jit/CodeGenerator.cpp:2348
#3  0x08618f59 in js::jit::LGetPropertyPolymorphicT::accept (this=0xf7aa6110, visitor=0xf7ab1000) at js/src/jit/LIR-Common.h:5333
#4  0x084a876b in js::jit::CodeGenerator::generateBody (this=this@entry=0xf7ab1000) at js/src/jit/CodeGenerator.cpp:4029
#5  0x084a8eb8 in js::jit::CodeGenerator::generate (this=this@entry=0xf7ab1000) at js/src/jit/CodeGenerator.cpp:7418
#6  0x085036cd in js::jit::GenerateCode (mir=mir@entry=0xf7aa1150, lir=0xf7aa4f90) at js/src/jit/Ion.cpp:1600
#7  0x08568257 in js::jit::CompileBackEnd (mir=mir@entry=0xf7aa1150) at js/src/jit/Ion.cpp:1621
#8  0x08569249 in IonCompile (optimizationLevel=<optimized out>, recompile=false, constructing=<optimized out>, osrPc=0xf7a96b35 "\343\201V", baselineFrame=0xffffb9e0, script=<optimized out>, cx=0xf7a87040) at js/src/jit/Ion.cpp:1983
#9  js::jit::Compile (cx=cx@entry=0xf7a87040, script=script@entry=..., osrFrame=osrFrame@entry=0xffffb9e0, osrPc=osrPc@entry=0xf7a96b35 "\343\201V", constructing=false, forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2138
#10 0x08569493 in js::jit::CanEnterAtBranch (cx=cx@entry=0xf7a87040, script=0xf5f49160, osrFrame=osrFrame@entry=0xffffb9e0, pc=pc@entry=0xf7a96b35 "\343\201V") at js/src/jit/Ion.cpp:2220
#11 0x08460e52 in EnsureCanEnterIon (stub=0xf7a21728, jitcodePtr=<synthetic pointer>, pc=0xf7a96b35 "\343\201V", script=..., frame=0xffffb9e0, cx=0xf7a87040) at js/src/jit/BaselineIC.cpp:779
#12 js::jit::DoWarmUpCounterFallback (cx=0xf7a87040, stub=0xf7a21728, frame=0xffffb9e0, infoPtr=0xffffb9bc) at js/src/jit/BaselineIC.cpp:943
#13 0xf7fcd8eb in ?? ()
#14 0xf7a21728 in ?? ()
#15 0xf7fc8a74 in ?? ()
eax	0x0	0
ebx	0x962972c	157456172
ecx	0xf7e2f88c	-136120180
edx	0x0	0
esi	0x1	1
edi	0xf7aa3ac8	-139838776
ebp	0xffffb4c8	4294948040
esp	0xffffb440	4294947904
eip	0x862dda4 <js::jit::MacroAssembler::loadUnboxedProperty<js::jit::Address>(js::jit::Address, JSValueType, js::jit::TypedOrValueRegister)+1652>
=> 0x862dda4 <js::jit::MacroAssembler::loadUnboxedProperty<js::jit::Address>(js::jit::Address, JSValueType, js::jit::TypedOrValueRegister)+1652>:	movl   $0x328,0x0
   0x862ddae <js::jit::MacroAssembler::loadUnboxedProperty<js::jit::Address>(js::jit::Address, JSValueType, js::jit::TypedOrValueRegister)+1662>:	call   0x8066680 <abort@plt>

Comment 1

[Christian Holler (:decoder)]

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

The "good" changeset has the timestamp "20150312160100" and the hash "69d61a70214d".
The "bad" changeset has the timestamp "20150312161054" and the hash "9083621b0e2e".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=69d61a70214d&tochange=9083621b0e2e

Comment 2

[Brian Hackett [Laid off!]]

Attachment: patch

loadUnboxedProperty should support loading an int32 property into a double register.

Comment 3

[Jan de Mooij [:jandem]]

Comment on attachment 8589060 [details] [diff] [review]
patch

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

::: js/src/jit/MacroAssembler.cpp
@@ +807,5 @@
> +              push(scratch);
> +              load32(address, scratch);
> +              convertInt32ToDouble(scratch, output.typedReg().fpu());
> +              pop(scratch);
> +              break;

I think we can do:

convertInt32ToDouble(address, output.typedReg().fpu());
break;

Comment 4

[Brian Hackett [Laid off!]]

Nice, done, though I had to add convertInt32ToDouble(BaseIndex, FloatRegister) methods for x86/x64/ARM.  I left MIPS alone because I didn't know how to implement it for that architecture and because the MIPS build is already busted anyways.

https://hg.mozilla.org/integration/mozilla-inbound/rev/678f89d62b39

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/678f89d62b39