Closed Bug 631788 Opened 13 years ago Closed 13 years ago

Assertion failure: unexpected constantly false guard detected, at jstracer.cpp:4444

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- .x+

People

(Reporter: decoder, Assigned: n.nethercote)

References

Details

(Keywords: assertion, testcase, Whiteboard: [softblocker], fixed-in-tracemonkey)

Attachments

(2 files)

The attached multi-file test case produces the mentioned assertion. Unpack the archive and run with "js -j -f main.js".

When passing through the first assertion in gdb, a second assertion pops up:

Assertion failure: "Constantly false guard detected": 0 (./nanojit/LIR.cpp:1059).
Assignee: general → nnethercote
blocking2.0: --- → ?
Whiteboard: [softblocker]
Here's a minimal reproducer:

  for (var j = 1; j < 10; ++j) { switch(0/j) { } }

It doesn't happen on i386 because on i386 the tracer uses tableswitch() for JSOP_TABLESWITCH.  On all other platforms it uses switchop().

More specifically, the division generates this LIR:

00018:   1  div
    ------------------------------ # JSOP_DIV
    gti1 = gti ldi2, strict/*0*/
    jt gti1 -> unpatched
    eqi2 = eqi ldi2, strict/*0*/
    xt1: xt eqi2 -> exit=0x1800598 pc=0x17f966a imacpc=(nil) sp+16 rp+0 OVERFLOW
    immi1 = immi -1
    eqi3 = eqi ldi2, immi1/*-1*/
    immi2 = immi 0x80000000
    immi3 = immi 1
    label2:
    divi1 = divi strict/*0*/, ldi2
    modi1 = modi divi1
    immi4 = immi 0
    eqi4 = eqi modi1, immi4/*0*/
    xf2: xf eqi4 -> exit=0x1800598 pc=0x17f966a imacpc=(nil) sp+16 rp+0 OVERFLOW
**  eqi5 = eqi divi1, immi4/*0*/
**  xt2: xt eqi5 -> exit=0x1800598 pc=0x17f966a imacpc=(nil) sp+16 rp+0 OVERFLOW
    i2d1 = i2d divi1
    sti.sp sp[0] = divi1

The lines marked "**" are key -- if divi1 equals zero, we exit.  NJ now knows that divi1 must be non-zero after that point.  Then when we compile the TABLESWITCH we generate:

    eqi6 = eqi divi1, 0
    xf eqi6

and NJ knows the xf will always exit.
Looks like our handling of switches is pretty sucky -- if we see any switch value other than the one we saw at record-time, we leave the trace.  Still, I guess it's hard to do much better.

This patch does the obvious thing -- just aborts tracing if it sees the test will always fail.  And it adds a test.
Attachment #510199 - Flags: review?(dmandelin)
Attachment #510199 - Flags: review?(dmandelin)
Attachment #510199 - Flags: review+
Attachment #510199 - Flags: approval2.0+
blocking2.0: ? → .x
http://hg.mozilla.org/tracemonkey/rev/808734375cf4
Whiteboard: [softblocker] → [softblocker], fixed-in-tracemonkey
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Depends on: 626398
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug631788.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: