The following testcase crashes on mozilla-central revision d7c76fe69e9a (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --enable-debug, run with --no-threads --fuzzing-safe --ion-eager): var int32x4 = SIMD.int32x4; var a = int32x4((4294967295), 200, 300, 400); addCase( new Array(Math.pow(2,12)) ); for ( var arg = "", i = 0; i < Math.pow(2,12); i++ ) {} addCase( a ); function addCase(object) { object.length } Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x000000000083c10d in js::jit::TypedObjectPrediction::hasKnownArrayLength (this=0x7fffffffc970, length=0x7fffffffc99c) at js/src/jit/TypedObjectPrediction.cpp:217 217 MOZ_ASSERT(ofArrayKind()); #0 0x000000000083c10d in js::jit::TypedObjectPrediction::hasKnownArrayLength (this=0x7fffffffc970, length=0x7fffffffc99c) at js/src/jit/TypedObjectPrediction.cpp:217 #1 0x000000000071dfc0 in js::jit::IonBuilder::jsop_length_fastPath (this=0x7fffffffcdf0) at js/src/jit/IonBuilder.cpp:8807 #2 0x000000000075bf33 in js::jit::IonBuilder::jsop_length (this=0x7fffffffcdf0) at js/src/jit/IonBuilder.cpp:8752 #3 0x0000000000758ff1 in js::jit::IonBuilder::inspectOpcode (this=0x7fffffffcdf0, op=JSOP_LENGTH) at js/src/jit/IonBuilder.cpp:1746 #4 0x000000000075a0b8 in js::jit::IonBuilder::traverseBytecode (this=0x7fffffffcdf0) at js/src/jit/IonBuilder.cpp:1336 #5 0x000000000075a9cb in js::jit::IonBuilder::buildInline (this=0x7fffffffcdf0, callerBuilder=<optimized out>, callerResumePoint=<optimized out>, callInfo=...) at js/src/jit/IonBuilder.cpp:914 #6 0x000000000075afa1 in js::jit::IonBuilder::inlineScriptedCall (this=0x1b03ba8, callInfo=..., target=<optimized out>) at js/src/jit/IonBuilder.cpp:4371 #7 0x000000000075cc10 in inlineSingleCall (targetArg=<optimized out>, callInfo=..., this=<optimized out>) at js/src/jit/IonBuilder.cpp:4761 #8 js::jit::IonBuilder::inlineSingleCall (this=<optimized out>, callInfo=..., targetArg=<optimized out>) at js/src/jit/IonBuilder.cpp:4752 #9 0x000000000075e293 in js::jit::IonBuilder::inlineCallsite (this=0x1b03ba8, targets=..., originals=..., lambda=<optimized out>, callInfo=...) at js/src/jit/IonBuilder.cpp:4809 #10 0x000000000075eccc in js::jit::IonBuilder::jsop_call (this=<optimized out>, argc=1, constructing=false) at js/src/jit/IonBuilder.cpp:5612 #11 0x0000000000759b0d in js::jit::IonBuilder::inspectOpcode (this=0x1b03ba8, op=JSOP_CALL) at js/src/jit/IonBuilder.cpp:1662 #12 0x000000000075a0b8 in js::jit::IonBuilder::traverseBytecode (this=0x1b03ba8) at js/src/jit/IonBuilder.cpp:1336 #13 0x000000000075fc66 in build (this=0x1b03ba8) at js/src/jit/IonBuilder.cpp:753 #14 js::jit::IonBuilder::build (this=0x1b03ba8) at js/src/jit/IonBuilder.cpp:651 #15 0x0000000000765c6e in IonCompile (optimizationLevel=<optimized out>, recompile=<optimized out>, executionMode=<optimized out>, constructing=<optimized out>, osrPc=<optimized out>, baselineFrame=<optimized out>, script=<optimized out>, cx=<optimized out>) at js/src/jit/Ion.cpp:1965 #16 js::jit::Compile (cx=0x1a07150, script=0x7ffff7e621a8, osrFrame=<optimized out>, osrPc=<optimized out>, constructing=<optimized out>, executionMode=<optimized out>, forceRecompile=false) at js/src/jit/Ion.cpp:2159 #17 0x0000000000766e15 in js::jit::CanEnterAtBranch (cx=0x1a07150, script=0x7ffff7e621a8, osrFrame=0x7fffffffdf80, pc=0x1af9819 "\343\201\232") at js/src/jit/Ion.cpp:2228 #18 0x0000000000623d60 in EnsureCanEnterIon (jitcodePtr=<synthetic pointer>, pc=0x1af9819 "\343\201\232", script=0x7ffff7e621a8, frame=0x7fffffffdf80, cx=0x1a07150, stub=<optimized out>) at js/src/jit/BaselineIC.cpp:823 #19 DoWarmUpCounterFallback (infoPtr=0x7fffffffdf58, frame=0x7fffffffdf80, stub=<optimized out>, cx=0x1a07150) at js/src/jit/BaselineIC.cpp:994 #20 js::jit::DoWarmUpCounterFallback (cx=0x1a07150, stub=<optimized out>, frame=0x7fffffffdf80, infoPtr=0x7fffffffdf58) at js/src/jit/BaselineIC.cpp:951 #21 0x00007ffff7f76be7 in ?? () #22 0x00007fffffffdf80 in ?? () #23 0x00007fffffffdf20 in ?? () #24 0x00000000019c52e0 in InterpretResumeInfo () #25 0x00007ffff7e556a0 in ?? () #26 0x00007ffff7f7ba8e in ?? () #27 0x0000000000000302 in ?? () #28 0x0000000001b01960 in ?? () #29 0x00007fffffffdf80 in ?? () #30 0x00007fffffffdf58 in ?? () #31 0x0000000000000000 in ?? () rax 0x0 0 rbx 0x7fffffffc970 140737488341360 rcx 0x7ffff6cb7910 140737333917968 rdx 0x0 0 rsi 0x7ffff6f8baa0 140737336883872 rdi 0x7ffff6f8a180 140737336877440 rbp 0x7fffffffc960 140737488341344 rsp 0x7fffffffc950 140737488341328 r8 0x7ffff7fe8740 140737354041152 r9 0x72746e65632d616c 8247338199356891500 r10 0x7fffffffc6e0 140737488340704 r11 0x7ffff6c3fc90 140737333427344 r12 0x7fffffffc99c 140737488341404 r13 0x1b0bb20 28359456 r14 0x7fffffffcbd8 140737488341976 r15 0x7fffffffcc28 140737488342056 rip 0x83c10d <js::jit::TypedObjectPrediction::hasKnownArrayLength(int*) const+109> => 0x83c10d <js::jit::TypedObjectPrediction::hasKnownArrayLength(int*) const+109>: movl $0x7b,0x0 0x83c118 <js::jit::TypedObjectPrediction::hasKnownArrayLength(int*) const+120>: callq 0x4049f0 <abort@plt> Marking s-s for now because this assertion seems to be related to array length prediction somehow, which might lead to bad things when done wrong.

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Is this something you can look at, Dan? Thanks.

I assume this bug is connected to the use of SIMD, so it only affects Nightly. I marked this as blocker for bug 1064540, since it seems to be related to the handling of SIMD in IonMonkey.

JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/035c49aafe08 user: Brian Hackett date: Thu Oct 30 08:45:28 2014 -0700 summary: Bug 1091010 - Optimize accesses to TypedObject.length, r=nmatsakis. This iteration took 397.345 seconds to run.

Brian, is bug 1091010 a likely regressor?

TypedObjectPrediction::hasKnownArrayLength requires the object to have array kind, which isn't really necessary since it could just return false on non-arrays. This patch fixes this and some similar cases. Previously, when passed the wrong input these will just lead to MOZ_CRASH'es.

I'm just going to mark this sec-high because it sounds kind of sketchy. Given that this is trunk-only and has a patch, it doesn't matter too much what it is rated, but adjust as desired.

Comment on attachment 8541854 [details] [diff] [review] patch Review of attachment 8541854 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/jit/TypedObjectPrediction.cpp @@ +147,5 @@ > // know its complete size. > return false; > + > + default: > + MOZ_CRASH("Bad prediction kind"); Nit: the code was purposefully written not to use `default` so that you get warnings when new cases are added to the enum. I consider you the de facto owner of this code now, though, so feel free to abandon that principle if you choose.

(In reply to Andrew McCreight [:mccr8] from comment #7) > I'm just going to mark this sec-high because it sounds kind of sketchy. > Given that this is trunk-only and has a patch, it doesn't matter too much > what it is rated, but adjust as desired. This can only MOZ_CRASH on bad inputs.

Thanks.

JSBugMon: This bug has been automatically verified fixed.