Closed Bug 868206 Opened 11 years ago Closed 11 years ago

Assertion failure: !minimalInterval(interval), at ion/BacktrackingAllocator.cpp

Categories

(Core :: JavaScript Engine, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla24

People

(Reporter: gkw, Assigned: bhackett1024)

References

Details

(Keywords: assertion, testcase, Whiteboard: [fuzzblocker])

Attachments

(3 files)

Attached file stack
Object.getOwnPropertyNames(this);

asserts js debug shell on m-c changeset da429c311864 with --ion-eager --ion-regalloc=backtracking at Assertion failure: !minimalInterval(interval), at ion/BacktrackingAllocator.cpp

Due to its simplicity, this blocks fuzzing with --ion-regalloc=backtracking
Flags: needinfo?(bhackett1024)
This testcase WFM on tip.  Does it still crash for you?
Flags: needinfo?(bhackett1024)
(In reply to Brian Hackett (:bhackett) from comment #1)
> This testcase WFM on tip.  Does it still crash for you?

Yes, it still reproduces on 64-bit non-threadsafe debug non-deterministic js shell on m-c changeset rev e19d0885977c.
Flags: needinfo?(bhackett1024)
Attached patch patchSplinter Review
OK, got this to repro with Gary's configure options from IRC.  The problematic instruction here was a Concat whose inputs were the same, and which it wanted to be in two different fixed registers.  The backtracking allocator didn't know how to satisfy this.
Assignee: general → bhackett1024
Attachment #747391 - Flags: review?(jdemooij)
Flags: needinfo?(bhackett1024)
Attachment #747391 - Flags: review?(jdemooij) → review+
Attached patch followupSplinter Review
After fixing this, noticed a couple existing issues where the backtracking allocator was broken.  With these, jit-tests pass with --ion-eager --ion-regalloc=backtracking.
Attachment #749498 - Flags: review?(jdemooij)
Comment on attachment 749498 [details] [diff] [review]
followup

Review of attachment 749498 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/ion/Lowering.cpp
@@ +484,5 @@
>      LFilterArguments *lir = new LFilterArguments(useFixed(string, CallTempReg0),
>                                                   tempFixed(CallTempReg1),
>                                                   tempFixed(CallTempReg2));
>  
> +    return assignSnapshot(lir) && add(lir, ins) && assignSafepoint(lir, ins);

Why does LFilterArguments need a safepoint if it does not use callVM?
The bailout in LFilterArguments happens after the call it makes, and holds the inputs to the FilterArguments live even though they might have been clobbered.  Those inputs are inputs to the FilterArguments instruction which the regalloc should be able to put in registers.  Using a safepoint causes an OsiPoint instruction after the FilterArguments to hold the inputs used in the bailout, and since the regalloc can't introduce moves between an instruction and its OsiPoint (as enforced by some nasty code in the allocator) this will force those inputs to be in memory.
Attachment #749498 - Flags: review?(jdemooij) → review+
https://hg.mozilla.org/mozilla-central/rev/3bfbd1ed214d
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.