When loading the page http://t.co/vFuddHb I get: Assertion failure: Unpossible rejoin!, at /home/dbaron/builds/ssd/mozilla-central/mozilla/js/src/methodjit/InvokeHelpers.cpp:1330 Top frame in the stack at the time of the assertion is something in: http://buyersguide.caranddriver.com/media/js/cd/CDdartSite.js I'm running a self-built Linux 64-bit debug build on top of mozilla-central revision cf1ba8f0dbf71900bb24d77b5a63ad82c279b113 xref bug 671943, bug 674391
(In reply to David Baron [:dbaron] from comment #0) > When loading the page http://t.co/vFuddHb I get: Note: this is reliably reproducable now, but I wouldn't expect it to stay that way forever.
Created attachment 558619 [details] [diff] [review] patch Cool bug. This message shows up when a stub call we did not expect to be able to trigger reompilation of jitcode manages to do so. In this case a call to StrictEq, which can't mutate state in a way that will cause recompilation. The recompilation was actually triggered after returning from the StrictEq, when we were restoring loop invariant state. If there are loop invariant temporaries, they get restored after making stub calls, and if there are copies of those temporaries on the stack we need to check that the restored value is the same as that copy (stub calls are allowed to mutate 'loop invariant' stuff, but in doing so cannot invalidate copies the compiler knows about). The StrictEq did not change the value of the loop invariant temporary, but it did clobber the copy made of the temporary --- the copy was one of the values popped by the opcode, and in the same stack slot used to store the result of the StrictEq. The fix just doesn't track copies of loop temporaries which are popped by the call being made, for StrictEq and a few other opcodes which both use REJOIN_NONE and push stuff.