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:...
Status: RESOLVED FIXED
fixed-in-jaegermonkey
: assertion
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: general
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-06 11:51 PDT by David Baron :dbaron: ⌚️UTC-7
Modified: 2011-09-22 14:15 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


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

Description David Baron :dbaron: ⌚️UTC-7 2011-09-06 11:51:29 PDT
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
Comment 1 David Baron :dbaron: ⌚️UTC-7 2011-09-06 11:52:40 PDT
(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.
Comment 2 Brian Hackett (:bhackett) 2011-09-06 14:40:34 PDT
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.
Comment 3 Brian Hackett (:bhackett) 2011-09-06 22:54:59 PDT
http://hg.mozilla.org/projects/jaegermonkey/rev/6a8947bcc821
Comment 4 Brian Hackett (:bhackett) 2011-09-22 14:15:32 PDT
https://hg.mozilla.org/mozilla-central/rev/9ca3d16d575c

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