Closed Bug 1109911 Opened 7 years ago Closed 7 years ago

Assertion failure: ofArrayKind(), at js/src/jit/TypedObjectPrediction.cpp:217

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla37
Tracking Status
firefox36 --- disabled
firefox37 --- verified
firefox-esr31 --- unaffected

People

(Reporter: decoder, Assigned: bhackett1024)

References

Details

(4 keywords, Whiteboard: [jsbugmon:update])

Attachments

(1 file)

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.
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:bisect]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
Whiteboard: [jsbugmon:bisect] → [jsbugmon:]
Is this something you can look at, Dan?  Thanks.
Flags: needinfo?(sunfish)
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.
Blocks: 1064540
Flags: needinfo?(sunfish)
Whiteboard: [jsbugmon:] → [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
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?
Blocks: 1091010
Flags: needinfo?(bhackett1024)
Attached patch patchSplinter Review
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.
Assignee: nobody → bhackett1024
Flags: needinfo?(bhackett1024)
Attachment #8541854 - Flags: review?(nmatsakis)
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.
Keywords: sec-high
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.
Attachment #8541854 - Flags: review?(nmatsakis) → review+
(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.
Keywords: sec-highsec-other
https://hg.mozilla.org/mozilla-central/rev/180ffdfd2d27
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.