The following testcase asserts on mozilla-central revision b672877ed046 (run with --ion-eager): var callStack = new Array(); var gTestcases = new Array(); function TestCase(n, d, e, a) gTestcases[gTc++] = this; function reportCompare (expected, actual, description) { var testcase = new TestCase("unknown-test-name", description, expected, actual); } function exitFunc (funcName) { var lastFunc = callStack.pop(); reportCompare(funcName, lastFunc, "Test driver failure wrong exit function "); } for ( gTc=0; gTc < gTestcases.length; gTc++ ) {} p = Proxy.create({ has: function() {} }) Object.prototype.__proto__ = p; function f(x) { var x0, x1, x2, x3, x4, x5, x6, x8, x9, x10; var e = exitFunc ('test') f(x - 1); } f(1000);

JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: 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 This iteration took 12.395 seconds to run.

Needinfo from Nicolas based on comment 1 :)

bug 796114 only caused some functions to be inlined where they were not inlined before. I don't think it is the source of this bug. Maybe the following test case will help finding another regression range. This error is similar to what appear in Bug 852202. The following testcase asserts on mozilla-central revision 8f5b1f9f580492a (run with --ion-eager): var gTc = 0; var gTestcases = new Array(); function TestCase() { gTestcases[gTc++] = this; } function reportCompare () { new TestCase(); } function exitFunc () { reportCompare(); } p = Proxy.create({ has: function() {} }); Object.prototype.__proto__ = p; function f(x) { var x0, x1; exitFunc(); f(x - 1); } f(11000);

JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 119980:e6d6b014a076 parent: 119968:d802d6faa080 user: Brian Hackett date: Sat Jan 26 13:21:27 2013 -0700 summary: Bug 832364 - Generate optimized paths for element accesses on native objects, r=jandem. This iteration took 94.862 seconds to run.

Thanks Nicolas, now the bisect points at Brian :) Needinfo on Brian, and bug 852202 might indeed be a dup.

Echoing comment 3, I don't see how bug 832364 could have caused this error. The crash is in some piece of Ion frame handling code that has nothing to do with what 832364 touched (decoder: can you make sure to post stack traces when filing bugs?). I think this is some super fragile failure that is very sensitive to the generated code, and someone who knows what ion::HandleException is supposed to be doing should look at it.

Here's the stack: Program received signal SIGSEGV, Segmentation fault. js::StackSegment::popRegs (this=<optimized out>, regs=<optimized out>) at /srv/repos/mozilla-central/js/src/vm/Stack.cpp:559 559 JS_ASSERT_IF(regs && contains(regs->fp()), regs->fp() == regs_->fp()->prev()); (gdb) bt #0 js::StackSegment::popRegs (this=<optimized out>, regs=<optimized out>) at /srv/repos/mozilla-central/js/src/vm/Stack.cpp:559 #1 0x00000000006ad6e2 in js::ContextStack::popFrame (this=0xeaf3c8, fg=...) at /srv/repos/mozilla-central/js/src/vm/Stack.cpp:1145 #2 0x000000000092a48b in ~FrameGuard (this=0xf4fe98, __in_chrg=<optimized out>) at ../vm/Stack.h:1787 #3 ~BailoutFrameGuard (this=0xf4fe98, __in_chrg=<optimized out>) at ../vm/Stack.h:1800 #4 ~Guards (this=0xf4fe60, __in_chrg=<optimized out>) at ../ion/Bailouts.h:121 #5 ~Maybe (this=0xf4fe60, __in_chrg=<optimized out>) at ./dist/include/mozilla/Util.h:161 #6 ~BailoutClosure (this=0xf4fe60, __in_chrg=<optimized out>) at ../ion/Bailouts.h:115 #7 js_delete<js::ion::BailoutClosure> (p=0xf4fe60) at ./dist/include/js/Utility.h:511 #8 js::ion::HandleException (rfe=0x7fffffffcaf8) at /srv/repos/mozilla-central/js/src/ion/IonFrames.cpp:307 #9 0x00007ffff7f914a5 in ?? () #10 0x0000000000006e26 in ?? () #11 0x00007fffffffcaf8 in ?? () #12 0x00007fffffffffff in ?? () #13 0x00007fffffffcb00 in ?? () #14 0x0000000000000000 in ?? ()

JSBugMon: Cannot process bug: Unknown exception (check manually)

JSBugMon: The testcase found in this bug no longer reproduces (tried revision f20b0ce9e528).

JSBugMon: Fix Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first good revision is: changeset: 127422:1821ba8e3afc parent: 127421:725c137c988a parent: 124862:3df2b971c106 user: Jan de Mooij date: Fri Mar 15 10:32:44 2013 +0100 summary: Merge from mozilla-inbound. This iteration took 160.493 seconds to run. Oops! We didn't test rev 725c137c988a, a parent of the blamed revision! Let's do that now. We did not test rev 725c137c988a because it is not a descendant of either 8f5b1f9f5804 or 475dc5f51bdb. Rev 725c137c988a: Updating... Compiling... Testing... [Uninteresting] It didn't crash. (10.024 seconds) good (not interesting) Bisect lied to us! Parent rev 725c137c988a was also good! Oops! We didn't test rev 3df2b971c106, a parent of the blamed revision! Let's do that now. Rev 3df2b971c106: Updating... Compiling... Testing... Exit status: CRASHED signal 11 (SIGSEGV) (0.643 seconds) bad (interesting) As expected, the parent's label is the opposite of the blamed rev's label. Perhaps we should expand the search to include the common ancestor of the blamed changeset's parents. The common ancestor of 725c137c988a and 3df2b971c106 is 6bbd7ce8308e. Rev 6bbd7ce8308e: Updating... Compiling... Testing... Exit status: CRASHED signal 11 (SIGSEGV) (0.642 seconds) bad (interesting) The following line is still under testing: Try setting -s to 6bbd7ce8308e, and -e to 475dc5f51bdb, and re-run autoBisect.

This probably got fixed by the BaselineCompiler landing, but bisection all the branches has gotten `hg bisect` confused.

I meant "bisection of all the merges".

Unlikely that it got fixed by the BC landing because the merge is much older. Closing as WFM for now.