"Assertion failed: _allocator.active[FST0] && ..." with lots of "%="

VERIFIED FIXED

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
9 years ago
7 years ago

People

(Reporter: Jesse Ruderman, Assigned: dvander)

Tracking

(Blocks: 2 bugs, {assertion, testcase, verified1.9.1})

Trunk
x86
Mac OS X
assertion, testcase, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-testsuite +
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
for each (let a in [2, 2, 2]) { a %= a; a %= a; }

Assertion failed: _allocator.active[FST0] && _fpuStkDepth == -1 || !_allocator.active[FST0] && _fpuStkDepth == 0 (../nanojit/Assembler.cpp:407)

Comment 1

9 years ago
Wow. WTF?

Comment 2

9 years ago
David this might be the modulo demotion code. We have to do another bug squashing day tomorrow. This stuff is piling up.

Comment 3

9 years ago
any idea what the LIR looks like that triggers this assert?  if its malformed (maybe float/int mismatch), maybe could catch it upstream.

Updated

9 years ago
Flags: blocking1.9.1+
(Assignee)

Comment 4

9 years ago
Created attachment 349520 [details] [diff] [review]
potential fix

LIR looks like:
js_dmod2 = js_dmod ( $stack2 $stack2 )
js_dmod3 = js_dmod ( js_dmod2 js_dmod2 )

asm_farg does FSTPQ twice which triggers this assert.

Simple fix might be to evict FST0 every time we use it as an input argument.  This generates a little more ugly code, but perhaps hint() should not be hinting at FST0 for fcall.

Any suggestions?
Attachment #349520 - Flags: review?(edwsmith)

Comment 5

9 years ago
If the simple fix works, go for it.  a more general fix:

Prescan the args, and if >1 are in FST0, then issue a FST(0) to pop the reg, and then change FSTPQ to FSTQ.  the result should be (reading forwards)

FSTQ
FSTQ
FST(0)
call fmod

with a little more code wrangling (passing around state flags between asm_call and asm_farg), the best code would be:

FSTQ
FSTPQ
call fmod

Updated

9 years ago
Attachment #349520 - Flags: review?(edwsmith) → review+
(Assignee)

Comment 6

9 years ago
From discussion on IRC, it seems like just evicting is easiest.  The heuristics get complicated trying to pre-scan the argument list.

Pushed fix w/ comments as changeset http://hg.mozilla.org/tracemonkey/rev/5d6e3e1e78ec
Assignee: general → danderson
Status: NEW → ASSIGNED
Whiteboard: fixed-in-tracemonkey

Updated

9 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 7

9 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9619b9eaea90
Keywords: fixed1.9.1

Comment 8

9 years ago
http://hg.mozilla.org/mozilla-central/rev/e8ed1a635e7d
/cvsroot/mozilla/js/tests/js1_7/regress/regress-465484.js,v  <--  regress-465484.js
initial revision: 1.1
Flags: in-testsuite+
Flags: in-litmus-

Comment 9

9 years ago
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1

Updated

9 years ago
Blocks: 506146

Comment 10

8 years ago
(In reply to comment #5)

Prescanning to generate optimal code seems like the best way to proceed, but a cheap prescan could simply note multiple args in FST0 and evict.

Comment 11

8 years ago
Sounds good. It's probably a 2-liner. Want to give it a try? Otherwise I can take this one.

Comment 12

8 years ago
(In reply to comment #11)
> Want to give it a try? 

I'm working on it, pottering my way through learning the nanojit data structures :) -- a review would be goodness when I have a patch, if you would.
(Reporter)

Updated

7 years ago
Severity: normal → critical
You need to log in before you can comment on or make changes to this bug.