Assertion failed: (((dr) & 0xfff) == (dr)) || (((-dr) & 0xfff) == (-dr)) (../nanojit/NativeARM.cpp:1394)

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
RESOLVED WORKSFORME
8 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
ARM
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Created attachment 419047 [details]
testcase (not fully reduced)

Assertion failed: (((dr) & 0xfff) == (dr)) || (((-dr) & 0xfff) == (-dr)) (../nanojit/NativeARM.cpp:1394)

TM rev 19c81ca38ab4+ on Ubuntu/ARM
The attachment looks like jsfunfuzz. Is that a mistake or am I missing something?
(Reporter)

Comment 2

8 years ago
It's part of jsfunfuzz, plus some JavaScript code generated by jsfunfuzz.
(Reporter)

Comment 3

8 years ago
Still happens on current tracemonkey branch (76e22cb4cbb5+).
I updated to the original changeset (19c81ca38ab4) and there was no such assertion on line 1934, and I couldn't find one that looked like that anywhere in NativeARM.cpp.  Likewise for more recent versions.

Jesse, can you copy the failing assertion from the code and tell us what line it's on?  Thanks.

(It looks like it's an issue with load/store displacements being greater than 12 bits, but I thought that was fixed with bug 519805.)
(Reporter)

Comment 5

8 years ago
The assertion is in a macro, and its condition involves another macro.

http://hg.mozilla.org/tracemonkey/file/6c3f2e826dec/js/src/nanojit/NativeARM.cpp#l1408

STR()
http://hg.mozilla.org/tracemonkey/file/6c3f2e826dec/js/src/nanojit/NativeARM.h#l667

isU12()
http://hg.mozilla.org/tracemonkey/file/6c3f2e826dec/js/src/nanojit/NativeARM.h#l177
I get the same crash on bug 490439, where I tried running something with a really large stack. (The original crash was different; look at comment 19.)

I haven't got any further with it, unfortunately, but it's still in my "to do" list.
I think this one is simple.  Stores on ARM have a maximum 12 bit displacement.  We allow for this in most cases, eg:

       case LIR_sti:
            if (isU12(-dr) || isU12(dr)) {
                STR(ra, rb, dr);
            } else {
                STR(ra, IP, 0);
                asm_add_imm(IP, rb, dr);
            }

but in the LIR_stfi and LIR_st32f cases we do not.  Jacob, you are most familiar with this code -- assuming you agree, would you like to whip up a patch?  The only difficulty is making sure that both 'dr' and 'dr+4' fit in the 12 bits.
(Reporter)

Comment 8

8 years ago
WFM with this testcase.  njn, do you know if the underlying bug was fixed?
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
(In reply to comment #8)
> WFM with this testcase.  njn, do you know if the underlying bug was fixed?

Pretty sure it hasn't been fixed.  Jacob?
Er. Yeah, it was fixed because I added a "asm_str" function that can accept arbitrary offsets. See bug 561977. The solution isn't terribly optimal for large offsets but I assumed that they were rare.

The floating-point loads appear safe. The only potential violation I can see is in asm_stkarg, but that case will never assert because stkd remains small.
Depends on: 561977
Depends on: 570694
You need to log in before you can comment on or make changes to this bug.