Closed
Bug 1080438
Opened 10 years ago
Closed 10 years ago
Crash [@ js::jit::RangeAnalysis::truncate]
Categories
(Core :: JavaScript Engine: JIT, defect)
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)
4.13 KB,
text/plain
|
Details | |
1.03 KB,
patch
|
nbp
:
review+
|
Details | Diff | Splinter Review |
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)
Reporter | ||
Comment 1•10 years ago
|
||
(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)
Assignee | ||
Comment 2•10 years ago
|
||
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 3•10 years ago
|
||
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)
Assignee | ||
Comment 4•10 years ago
|
||
(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.
Updated•10 years ago
|
Attachment #8502857 -
Flags: review+
Assignee | ||
Comment 5•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/47f47eea45d3
Comment 6•10 years ago
|
||
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.
Description
•