IonMonkey: LiveRangeAllocator assumes there always exists a block after the osrBlock (in post-order)

RESOLVED FIXED in mozilla23

Status

()

Core
JavaScript Engine
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: djvj, Unassigned)

Tracking

unspecified
mozilla23
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Found this helping track down dromaeo oranges for patch to bug 865059.

LiveRangeAllocator::buildLivenessInfo uses a worklist of blocks in a loop to iterate through.  When iterating to the next block in this list, it skips osrBlocks.  However, it assumes that if the next block is an osrBlock, then the list contains at least one more non-osr block.

This seems not to be the a valid assumption.  At least, brian's scriptAnalysis patch in bug 865059 seems to trigger situations where this implicit assumption is no longer true.

Before this fix, I was able to reproduce some crashes on dromaeo_css with the original patch for bug 865059 applied.  After this issue is fixed, it doesn't show up, at least in debug builds.  Will test more.
(Reporter)

Comment 1

5 years ago
Created attachment 746487 [details] [diff] [review]
Fix.
Attachment #746487 - Flags: review?(bhackett1024)
Attachment #746487 - Flags: review?(bhackett1024) → review+
(Reporter)

Comment 2

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/0a50d67075be
https://hg.mozilla.org/mozilla-central/rev/0a50d67075be
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Blocks: 875276
You need to log in before you can comment on or make changes to this bug.