The following testcase asserts on mozilla-central revision 3acbf951b3b1 (run with --ion-eager): function getTestCaseResult(expected, actual) { return actual == expected; } getTestCaseResult('', ''); exhaustiveSliceTest([]); function exhaustiveSliceTest(a) { var x = 0; var passed = true; for (x = -(2 + a.length); x <= (2 + a.length); x++) passed = false; getTestCaseResult(true, passed); }

Crash looks like a null-deref: Program received signal SIGSEGV, Segmentation fault. 0x0837da99 in isTagged (this=0x1c) at /srv/repos/mozilla-central/js/src/ion/LIR.h:90 90 return !!(bits_ & TAG_MASK); (gdb) bt #0 0x0837da99 in isTagged (this=0x1c) at /srv/repos/mozilla-central/js/src/ion/LIR.h:90 #1 kind (this=0x1c) at /srv/repos/mozilla-central/js/src/ion/LIR.h:134 #2 isArgument (this=0x1c) at /srv/repos/mozilla-central/js/src/ion/LIR.h:164 #3 js::ion::LinearScanAllocator::populateSafepoints (this=0xffffc59c) at /srv/repos/mozilla-central/js/src/ion/LinearScan.cpp:536 #4 0x083817ff in js::ion::LinearScanAllocator::go (this=0xffffc59c) at /srv/repos/mozilla-central/js/src/ion/LinearScan.cpp:1169 #5 0x083290bd in js::ion::GenerateLIR (mir=0x8655860) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1045 #6 0x0832a721 in CompileBackEnd (mir=0x8655860, maybeMasm=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1125 #7 compile (autoDelete=<synthetic pointer>, builder=0x8655860, this=<optimized out>, graph=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1316 #8 IonCompile<js::ion::SequentialCompileContext> (compileContext=..., constructing=false, osrPc=0x0, fun=(JSFunction *) 0x8641930 [object ], script=<optimized out>, cx=0x85d7e38) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1257 #9 js::ion::Compile<js::ion::SequentialCompileContext> (cx=0x85d7e38, script=0xf7429178, fun=(JSFunction * const) 0xf7433020 [object Function "exhaustiveSliceTest"], osrPc=0x0, constructing=false, compileContext= ...) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1469 #10 0x0832c303 in js::ion::CanEnter (cx=0x85d7e38, script=0xf7429178, fp=..., isConstructing=false) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1568 #11 0x080f999c in js::Interpret (cx=0x85d7e38, entryFrame=0xf7698028, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:2387 #12 0x080fd8a3 in js::RunScript (cx=0x85d7e38, fp=0xf7698028) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:341 #13 0x0810393a in ExecuteKernel (result=0x0, evalInFrame=..., thisv=..., scopeChainArg=..., script=0xf7429088, cx=0x85d7e38, type=<optimized out>) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:529 #14 js::Execute (cx=0x85d7e38, script=0xf7429088, scopeChainArg=(JSObject &) @0xf7425040 [object global] delegate, rval=0x0) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:569 #15 0x0806a048 in JS_ExecuteScript (cx=0x85d7e38, objArg=(JSObject *) 0xf7425040 [object global] delegate, scriptArg=0xf7429088, rval=0x0) at /srv/repos/mozilla-central/js/src/jsapi.cpp:5524 #16 0x0805527e in Process (cx=0x85d7e38, obj_=<optimized out>, filename=0xffffd19f "min.js", forceTTY=false) at /srv/repos/mozilla-central/js/src/shell/js.cpp:473 #17 0x080588c6 in ProcessArgs (op=0xffffcee0, obj_=(JSObject *) 0xf7425040 [object global] delegate, cx=0x85d7e38) at /srv/repos/mozilla-central/js/src/shell/js.cpp:5083 #18 Shell (cx=0x85d7e38, op=0xffffcee0, envp=0xffffd004) at /srv/repos/mozilla-central/js/src/shell/js.cpp:5120 #19 0x0804b710 in main (argc=3, argv=0xffffcff4, envp=0xffffd004) at /srv/repos/mozilla-central/js/src/shell/js.cpp:5344 (gdb) x /i $pc => 0x837da99 <js::ion::LinearScanAllocator::populateSafepoints()+633>: mov 0x1c(%ecx),%eax (gdb) info reg ecx ecx 0x0 0 Marking s-s though until triaged, because the assertion can indicate a security problem.

I get a different crash on x64 that looks more easily debuggable: Assertion failure: ins->type() == MIRType_Value, at /home/sstangl/dev/mozilla-inbound/js/src/ion/MIR.h:1852

(In reply to Sean Stangl [:sstangl] from comment #2) > I get a different crash on x64 that looks more easily debuggable: > > Assertion failure: ins->type() == MIRType_Value, at > /home/sstangl/dev/mozilla-inbound/js/src/ion/MIR.h:1852 That's what the bug subject says, yes. I usually post a stack of the opt crash because it's necessary to triage/estimate the security impact. A debug trace is useless for that if it's an assertion.

Christian: is there a useful bisect of when this started happening? That might provide a clue to what the bug is.

JSBugMon: Cannot process bug: Error: Failed to compile specified revision 3acbf951b3b1 (maybe try another?)

I finally figured out why JSBugMon did not process this bug appropriately. The specified revision doesn't seem to compile in the bot, but the error was not propagated properly. Here's the bisect: The first bad revision is: changeset: 122585:437c955ff06d user: Nicolas B. Pierron date: Wed Jan 30 07:41:01 2013 -0800 summary: Bug 796114 - Inline with type-checked arguments. r=h4writer Needinfo from Nicolas based on that, also Ccing h4writer who could help figuring this out :)

This looks like a typical type problem. But I thought we covered them by now with bug 849781. Now the problem is that I cannot reproduce this on tip build-32-debug build...

Setting the revision to something not near tip, so we can see if this was fixed by bug 849781.

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 139b6ba547fa). JSBugMon: Fix Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first good revision is: changeset: 124192:501fea96c33a user: Nicolas B. Pierron date: Thu Mar 07 17:48:51 2013 -0800 summary: Bug 844452 - Box boolean inputs on MCompare-strings. r=dvander This iteration took 123.787 seconds to run.