975446 - Assertion failure: args[0].isObject(), at vm/SelfHosting.cpp:472 or Crash [@ js::intrinsic_UnsafeGetReservedSlot] with SIMD

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 7010ab83a06e (run with --fuzzing-safe --ion-compile-try-catch):


var float32x4 = SIMD.float32x4;
var f = float32x4(11, 22, 33, 44);
assertEq(f,1);

Comment 1

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

Comment 2

[Christian Holler (:decoder)]

Looks like a null-deref:


Program received signal SIGSEGV, Segmentation fault.
js::intrinsic_UnsafeGetReservedSlot (cx=0x158b260, argc=<optimized out>, vp=0x15efb28) at js/src/vm/SelfHosting.cpp:475
475         args.rval().set(args[0].toObject().getReservedSlot(args[1].toPrivateUint32()));
#0  js::intrinsic_UnsafeGetReservedSlot (cx=0x158b260, argc=<optimized out>, vp=0x15efb28) at js/src/vm/SelfHosting.cpp:475
#1  0x00000000007d8a72 in CallJSNative (args=..., native=0x79df60 <js::intrinsic_UnsafeGetReservedSlot(JSContext*, unsigned int, JS::Value*)>, cx=0x158b260) at js/src/jscntxtinlines.h:230
#2  js::Invoke (cx=0x158b260, args=..., construct=<optimized out>) at js/src/vm/Interpreter.cpp:476
#3  0x00000000007cc999 in Interpret (cx=0x158b260, state=...) at js/src/vm/Interpreter.cpp:2608
#4  0x00000000007d854e in js::RunScript (cx=0x158b260, state=...) at js/src/vm/Interpreter.cpp:423
#5  0x00000000007d8953 in RunScript (state=..., cx=0x158b260) at js/src/vm/Interpreter.cpp:390
#6  js::Invoke (cx=0x158b260, args=..., construct=<optimized out>) at js/src/vm/Interpreter.cpp:495
#7  0x00000000007d947b in js::Invoke (cx=0x158b260, thisv=..., fval=..., argc=0, argv=<optimized out>, rval=...) at js/src/vm/Interpreter.cpp:532
rax     0x0     0
rip     0x79df71 <js::intrinsic_UnsafeGetReservedSlot(JSContext*, unsigned int, JS::Value*)+17>
=> 0x79df71 <js::intrinsic_UnsafeGetReservedSlot(JSContext*, unsigned int, JS::Value*)+17>:     mov    (%rax),%rcx

Comment 3

[Till Schneidereit [:till]]

Niko, either you or Ivan should look into this, I think.

Comment 4

[Christian Holler (:decoder)]

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

The "good" changeset has the timestamp "20140220102129" and the hash "7a5cbe4dadf8".
The "bad" changeset has the timestamp "20140220102430" and the hash "cc73b1f7a47d".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7a5cbe4dadf8&tochange=cc73b1f7a47d

Comment 5

[Niko Matsakis [:nmatsakis]]

Attachment: Bug975446.diff

Comment 6

[Steve Fink [:sfink] [:s:]]

Comment on attachment 8393057 [details] [diff] [review]
Bug975446.diff

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

Hm, when I was reading through TypedObject.js, my first thought was that all those scary macros at the top ought to have type assertions in them.

Maybe I'll wait to demand something like that until after the current dust settles.

Comment 7

[Niko Matsakis [:nmatsakis]]

Oh, I see you just mentioned this. Yeah I was thinking the same and I think I mentioned it in another bug. Not sure why I didn't do that in the first place.

Comment 8

[Niko Matsakis [:nmatsakis]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9a93e25e1c2f

Comment 9

[Niko Matsakis [:nmatsakis]]

Try run: https://tbpl.mozilla.org/?tree=Try&rev=171a0e96143e

Comment 10

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

https://hg.mozilla.org/mozilla-central/rev/9a93e25e1c2f