ASSERT(offset) when 0 is a valid offset on ARM.

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: jbramley, Assigned: jbramley)

Tracking

unspecified
ARM
Linux
Points:
---

Firefox Tracking Flags

(blocking2.0 .x+, fennec2.0+)

Details

(Assignee)

Description

7 years ago
On current tip (42063595d186):

harmony-jacob-0:~/moz/tm.d$ ./js -m /work/moz/mozilla.org/tracemonkey/js/src/jit-test/tests/basic/bug489098.js
Assertion failure: offset, at /work/moz/tm/js/src/methodjit/MonoIC.cpp:253
Aborted

The fault is here: 

---- [ MonoIC.cpp line 187 ] ----

    Label start = masm.label();

    DataLabel32 shapeLabel;
    Jump guard = masm.branch32WithPatch(Assembler::NotEqual, ic->shapeReg, Imm32(obj->shape()),
                                        shapeLabel);

---- [ MonoIC.cpp line 250 ] ----

    int offset = linker.locationOf(shapeLabel) - linker.locationOf(start);
    ic->extraShapeGuard = offset;
    JS_ASSERT(ic->extraShapeGuard == offset);
    JS_ASSERT(offset);

----

On ARM, branch32WithPatch can put shapeLabel at the start of the
instruction sequence, so 'offset' can be zero (and this is correct).

On the face of it, it looks like I can just strip out the assertion.
However, the assertion (and much of this code) was added as part of bug
627486, and I'm not on the access list for it so I'm not sure what it's
about.

Can this assertion (and others like it) just be stripped?
(Assignee)

Updated

7 years ago
Summary: ARM breakage: ASSERT(offset) when 0 is a valid offset. → ASSERT(offset) when 0 is a valid offset on ARM.
(Assignee)

Comment 1

7 years ago
Ok, disabling the offending assertion on current tip (9ecbccbaff7b) causes the engine to enter an infinite loop. Something is wrong here.
(Assignee)

Comment 2

7 years ago
I verified that 410fe81fff16 triggers both the assertion failure and the infinite loop (though the loop is hidden by the failing assertion). The problem is related to setgname, and the infinite loop doesn't appear to leave JIT-compiled code. I'm not certain what's causing it, but I suspect one of the linkJumps is linking to the wrong place.
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0+
blocking2.0: --- → ?
blocking2.0: ? → .x
(Assignee)

Comment 3

7 years ago
According to cdleary (on IRC), this was independently fixed by dvander shortly after I filed this bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.