Closed Bug 854021 Opened 9 years ago Closed 9 years ago

IonMonkey: ParallelArray: Crash [@ js::ion::MDefinition::addUse] or [@ js::ion::MResumePoint::setOperand] or Assertion failure: index < length_, at ion/FixedList.h with --enable-threadsafe

Categories

(Core :: JavaScript Engine, defect)

Other Branch
x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla22
Tracking Status
firefox19 --- unaffected
firefox20 --- unaffected
firefox21 --- unaffected
firefox22 --- fixed
firefox-esr17 --- unaffected
b2g18 --- unaffected

People

(Reporter: gkw, Assigned: shu)

References

Details

(4 keywords, Whiteboard: [jsbugmon:][adv-main22-])

Crash Data

Attachments

(2 files)

Attached file stack
ParallelArray(7, function ([y]) {})

asserts js debug shell on ionmonkey changeset f035cd0ee56e with --ion-eager at Assertion failure: index < length_, at ion/FixedList.h and crashes js opt shell at js::ion::MDefinition::addUse

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   125968:e5978106c61a
parent:      125839:280e5ed3f0b7
parent:      125967:1d6fe70c79c5
user:        Jan de Mooij
date:        Thu Mar 21 11:23:12 2013 +0100
summary:     Merge from mozilla-central.

Not all ancestors of this changeset have been checked.
Use bisect --extend to continue the bisection from
the common ancestor, 0bba6ba92467.

This iteration took 186.900 seconds to run.

Oops! We didn't test rev 1d6fe70c79c5, a parent of the blamed revision! Let's do that now.
Rev 1d6fe70c79c5: Updating... Compiling... Testing... good (Exit code 0)
As expected, the parent's label is the opposite of the blamed rev's label.

s-s because baseline compiler is about to land soon (moving forward, we're likely to file them as s-s), and this involves ParallelArrays.
Whiteboard: [jsbugmon:update] → [jsbugmon:]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
--enable-threadsafe is needed for this, and I also reproduced this with --enable-more-deterministic though I'm not sure if the latter is needed.
Crash Signature: [@ js::ion::MDefinition::addUse] → [@ js::ion::MDefinition::addUse] [@ js::ion::MResumePoint::setOperand]
Summary: BaselineCompiler: Crash [@ js::ion::MDefinition::addUse] or Assertion failure: index < length_, at ion/FixedList.h → BaselineCompiler: Crash [@ js::ion::MDefinition::addUse] or [@ js::ion::MResumePoint::setOperand] or Assertion failure: index < length_, at ion/FixedList.h
Summary: BaselineCompiler: Crash [@ js::ion::MDefinition::addUse] or [@ js::ion::MResumePoint::setOperand] or Assertion failure: index < length_, at ion/FixedList.h → BaselineCompiler: Crash [@ js::ion::MDefinition::addUse] or [@ js::ion::MResumePoint::setOperand] or Assertion failure: index < length_, at ion/FixedList.h with --enable-threadsafe
Looks like a ParallelArray bug, I can reproduce this on inbound with --no-jm --ion-eager:

$ ./js --no-jm --ion-eager
js> ParallelArray(7, function ([y]) {})
Assertion failure: index < length_, at js/src/ion/FixedList.h:63
Bus error: 10
No longer blocks: BaselineFuzz
Summary: BaselineCompiler: Crash [@ js::ion::MDefinition::addUse] or [@ js::ion::MResumePoint::setOperand] or Assertion failure: index < length_, at ion/FixedList.h with --enable-threadsafe → Crash [@ js::ion::MDefinition::addUse] or [@ js::ion::MResumePoint::setOperand] or Assertion failure: index < length_, at ion/FixedList.h with --enable-threadsafe
Summary: Crash [@ js::ion::MDefinition::addUse] or [@ js::ion::MResumePoint::setOperand] or Assertion failure: index < length_, at ion/FixedList.h with --enable-threadsafe → IonMonkey: ParallelArray: Crash [@ js::ion::MDefinition::addUse] or [@ js::ion::MResumePoint::setOperand] or Assertion failure: index < length_, at ion/FixedList.h with --enable-threadsafe
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   125555:b00eb1ef1517
user:        Nicholas D. Matsakis
date:        Tue Mar 19 22:12:27 2013 -0400
summary:     Bug 829602 - Enable self-hosted parallelarray r=dvander,till
Blocks: 829602
Attached patch fix + testcaseSplinter Review
CompileInfo should be gotten from the |pred| and not block, since they could be different due to inlining.
Attachment #729820 - Flags: review?(nmatsakis)
Assignee: general → shu
Attachment #729820 - Flags: review?(nmatsakis) → review+
https://hg.mozilla.org/mozilla-central/rev/259ddfa06cff
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Whiteboard: [jsbugmon:] → [jsbugmon:][adv-main22-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.