Closed Bug 1080438 Opened 10 years ago Closed 10 years ago

Crash [@ js::jit::RangeAnalysis::truncate]

Categories

(Core :: JavaScript Engine: JIT, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox35 --- affected

People

(Reporter: gkw, Assigned: sunfish)

References

Details

(Keywords: crash, regression, testcase, Whiteboard: [jsbugmon:update])

Crash Data

Attachments

(2 files)

function f(y) {
    (0 < -1) ? (1 || 0) : -y >>> 0
}
for (var j = 0; j < 1; j++) {
    try {
        f(1)
    } catch (e) {}
}

crashes js debug shell on m-c changeset f0bb13ef0ee4 with --ion-eager --no-threads --ion-gvn=off at js::jit::RangeAnalysis::truncate.

Debug configure options:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --enable-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

=== Tinderbox Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20140917100058" and the hash "33bef5d1f9bb".
The "bad" changeset has the timestamp "20140917102756" and the hash "ce0a75f9481b".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=33bef5d1f9bb&tochange=ce0a75f9481b

Dan, is bug 1029830 a possible regressor?
Flags: needinfo?(sunfish)
Attached file stack
(lldb) bt 5
* thread #1: tid = 0x80734, 0x00000001003cd1c4 js-dbg-opt-64-dm-nsprBuild-darwin-f0bb13ef0ee4`js::jit::RangeAnalysis::truncate() [inlined] js::jit::Range::hasInt32LowerBound(this=0x0000000000000000, this=0x0000000000000000) const at RangeAnalysis.h:446, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x4)
  * frame #0: 0x00000001003cd1c4 js-dbg-opt-64-dm-nsprBuild-darwin-f0bb13ef0ee4`js::jit::RangeAnalysis::truncate() [inlined] js::jit::Range::hasInt32LowerBound(this=0x0000000000000000, this=0x0000000000000000) const at RangeAnalysis.h:446
    frame #1: 0x00000001003cd1c4 js-dbg-opt-64-dm-nsprBuild-darwin-f0bb13ef0ee4`js::jit::RangeAnalysis::truncate() [inlined] js::jit::Range::hasInt32Bounds(this=0x0000000000000000, this=0x0000000000000000) const at RangeAnalysis.h:455
    frame #2: 0x00000001003cd1c4 js-dbg-opt-64-dm-nsprBuild-darwin-f0bb13ef0ee4`js::jit::RangeAnalysis::truncate() [inlined] js::jit::MDefinition::range(this=<unavailable>, this=0x0000000000000000) const + 17 at RangeAnalysis.h:460
    frame #3: 0x00000001003cd1b3 js-dbg-opt-64-dm-nsprBuild-darwin-f0bb13ef0ee4`js::jit::RangeAnalysis::truncate() [inlined] js::jit::RangeAnalysis::alloc(this=0x00007fff5fbfe9c8, alloc=0x0000000105000420, truncated=<unavailable>) const + 201 at RangeAnalysis.cpp:2707
    frame #4: 0x00000001003cd0ea js-dbg-opt-64-dm-nsprBuild-darwin-f0bb13ef0ee4`js::jit::RangeAnalysis::truncate(this=0x00007fff5fbfe9c8) + 2378 at RangeAnalysis.cpp:2829
(lldb)
This patch removes MOZ_ASSERT(input->range()->isInt32()). In the testcase, at the point of this assert, |input| is in an unreachable block, so range analysis didn't bother to compute a range for it, so input->range() is null, so we crash. The assert isn't all that meaningful anyway, so I propose just removing it.
Assignee: nobody → sunfish
Attachment #8502857 - Flags: review?(nicolas.b.pierron)
Flags: needinfo?(sunfish)
Comment on attachment 8502857 [details] [diff] [review]
remove-assert.patch

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

If |input| is in an unreachable block, why does |truncated| still refers to it without being it-self in an unreachable block?  In which case, I wonder why AdjustTruncateInputs (RangeAnalysis::truncate) visits unreachable blocks.
Attachment #8502857 - Flags: review?(nicolas.b.pierron)
(In reply to Nicolas B. Pierron [:nbp] from comment #3)
> Comment on attachment 8502857 [details] [diff] [review]
> remove-assert.patch
> 
> Review of attachment 8502857 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> If |input| is in an unreachable block, why does |truncated| still refers to
> it without being it-self in an unreachable block?  In which case, I wonder
> why AdjustTruncateInputs (RangeAnalysis::truncate) visits unreachable blocks.

In the testcase, |truncated| is a phi. One of its inputs is still reachable, so |truncated| itself is still reachable. In theory such a phi could be eliminated, but range analysis doesn't currently do optimizations like that while it's running.
Attachment #8502857 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/47f47eea45d3
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.