Last Comment Bug 684943 - Assertion failure: Unpossible rejoin!, at js/src/methodjit/InvokeHelpers.cpp:1330
: Assertion failure: Unpossible rejoin!, at js/src/methodjit/InvokeHelpers.cpp:...
: assertion
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
-- normal (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on:
  Show dependency treegraph
Reported: 2011-09-06 11:51 PDT by David Baron :dbaron: ⌚️UTC-8
Modified: 2011-09-22 14:15 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (13.49 KB, patch)
2011-09-06 14:40 PDT, Brian Hackett (:bhackett)
dvander: review+
Details | Diff | Splinter Review

Description User image David Baron :dbaron: ⌚️UTC-8 2011-09-06 11:51:29 PDT
When loading the page 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:

I'm running a self-built Linux 64-bit debug build on top of mozilla-central revision cf1ba8f0dbf71900bb24d77b5a63ad82c279b113

xref bug 671943, bug 674391
Comment 1 User image David Baron :dbaron: ⌚️UTC-8 2011-09-06 11:52:40 PDT
(In reply to David Baron [:dbaron] from comment #0)
> When loading the page I get:

Note:  this is reliably reproducable now, but I wouldn't expect it to stay that way forever.
Comment 2 User image Brian Hackett (:bhackett) 2011-09-06 14:40:34 PDT
Created attachment 558619 [details] [diff] [review]

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.
Comment 3 User image Brian Hackett (:bhackett) 2011-09-06 22:54:59 PDT
Comment 4 User image Brian Hackett (:bhackett) 2011-09-22 14:15:32 PDT

Note You need to log in before you can comment on or make changes to this bug.