970261 - Assertion failure: !used(), at jit/shared/Assembler-shared.h:360

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision f550b112a19b (x86 ARM simulator build, run with --fuzzing-safe --arm-sim-icache-checks --ion-eager --ion-check-range-analysis --ion-regalloc=backtracking):


function f1() {
    return !!([1].x++) * 0.1;
} 
function rnd(n) {
  return Math.floor(f1() * n)
};
function f2(d, b) {
  rnd(4);
  return f2();
}
f2();

Comment 1

[Douglas Crosher [:dougc]]

Looks like problems in the OOM paths.  The assertion does not look reliable - the OOM might have occurred after the label was used.

Comment 2

[Christian Holler (:decoder)]

Yea I think this assertion caused lots of problems before with OOM conditions and we even considered removing it before. If in this case it's also an OOM (and not some other, more important bug), then I'd really vote for killing this assertion.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Douglas, you also mentioned OOM in a possibly-related bug 955822.

Comment 4

[Douglas Crosher [:dougc]]

(In reply to Gary Kwong [:gkw] [:nth10sd] catching up on email/bugmail from comment #3)
> Douglas, you also mentioned OOM in a possibly-related bug 955822.

Sorry, I misread the code, it's not an OOM issue but clearly another ARM constant pool packing failure.  It's being worked on.

Comment 5

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 951e3a671279).

Comment 6

[Christian Holler (:decoder)]

JSBugMon: Fix Bisection requested, failed due to error (try manually).

Comment 7

[Christian Holler (:decoder)]

I retested this and it still reproduces.

Comment 8

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision f92e4d13b3c6).

Comment 9

[Brian Hackett [Laid off!]]

I can't reproduce this, can you still do so decoder?  Does anyone know if this is a backtracking allocator bug, or an ARM assembler bug (i.e. comment 4)?

Comment 10

[Douglas Crosher [:dougc]]

(In reply to Brian Hackett (:bhackett) from comment #9)
> I can't reproduce this, can you still do so decoder?  Does anyone know if
> this is a backtracking allocator bug, or an ARM assembler bug (i.e. comment
> 4)?

It appeared to be a problem in the OOM paths, and not a backtracking allocator bug.

Comment 4 noted that a constant pool packing consistency check failed, and this caused a bail out from compilation like an OOM. The assertion failure looks like a poorly handled OOM path.

The assembler no longer has these constant pool packing failures and the bailout path on longer exists so this test case is not expected to reproduce the assertion failure.

There might still be issues with the OOM paths, but these could use targeted testing.

I suggest closing this bug.