The default bug view has changed. See this FAQ.

Assertion failure: Unpossible rejoin!, at js/src/methodjit/InvokeHelpers.cpp:1330

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: dbaron, Unassigned)

Tracking

({assertion})

Trunk
x86_64
Linux
assertion
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-jaegermonkey)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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
(Reporter)

Comment 1

6 years ago
(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.
Whiteboard: js-triage-needed
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.
Attachment #558619 - Flags: review?(dvander)
Attachment #558619 - Flags: review?(dvander) → review+
http://hg.mozilla.org/projects/jaegermonkey/rev/6a8947bcc821
Whiteboard: js-triage-needed → fixed-in-jaegermonkey
https://hg.mozilla.org/mozilla-central/rev/9ca3d16d575c
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.