Closed Bug 854021 Opened 12 years ago Closed 12 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+
Status: NEW → RESOLVED
Closed: 12 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.

Attachment

General

Created:
Updated:
Size: