If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

TI: Assertion failure: Unpossible rejoin!, at methodjit/InvokeHelpers.cpp:1328

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: decoder, Unassigned)

Tracking

(Blocks: 2 bugs, {assertion, testcase})

Trunk
x86_64
Linux
assertion, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Created attachment 548611 [details]
Test case for shell (see README file inside).

The attached testcase asserts on TI revision bd40ad1be9d8 (run main.js with options -j -m -n -a). This seems very complex, cannot get it into a single file, but got it greatly reduced from its original form.
WFM, I just get:

ReferenceError: expect is not defined
ReferenceError: startTest is not defined

Can you paste the stack traces from the last few calls to js_GC, and/or the output when setting the JMFLAGS environment variable to 'recompile'?
(Reporter)

Comment 2

6 years ago
Created attachment 549326 [details]
Stacks of last three calls to js_GC

Here are the stacks of the last three calls to js_GC. Will attach the other information afterwards. If that is not enough, I can also simply provide you a shell with gdb so you can debug it on the fuzzing box. It's an Ubuntu (64 bit).
(Reporter)

Comment 3

6 years ago
Created attachment 549328 [details]
Output of JMFLAGS="recompile"
(In reply to comment #2)
> Created attachment 549326 [details]
> Stacks of last three calls to js_GC
> 
> Here are the stacks of the last three calls to js_GC. Will attach the other
> information afterwards. If that is not enough, I can also simply provide you
> a shell with gdb so you can debug it on the fuzzing box. It's an Ubuntu (64
> bit).

Ah, this does it, the problem is that js_IteratorNext can GC and throw us into the interpreter, but we don't rejoin from calls to it.  Thought that this function couldn't GC, maybe I should be eating my own dogfood though and using the reports for GC callers at sixgill.mozilla.org, since it's pretty clear what's going on there.
http://hg.mozilla.org/projects/jaegermonkey/rev/e5b57c9ebbe9

Side note: IterNext used REJOIN_NONE instead of REJOIN_FALLTHROUGH because it used to be called in the middle of JSOP_FOR* opcodes.  Without the fix from bug 648175 that removed these opcodes and made ITERNEXT its own opcode, being able to rejoin from an IterNext would have been extremely complicated.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Updated

6 years ago
Blocks: 676763
(Reporter)

Comment 6

5 years ago
A testcase for this bug was automatically identified at js/src/jit-test/tests/jaeger/recompile/bug674391.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.