Closed
Bug 950462
Opened 11 years ago
Closed 10 years ago
Assertion failure: false (MOZ_ASSUME_UNREACHABLE(unexpected type)), at jit/Lowering.cpp:1696 or Crash [@ js::jit::LIRGenerator::visitToDouble]
Categories
(Core :: JavaScript Engine: JIT, defect)
Tracking
()
VERIFIED
FIXED
mozilla29
Tracking | Status | |
---|---|---|
firefox27 | --- | unaffected |
firefox28 | --- | unaffected |
firefox29 | + | fixed |
firefox-esr24 | --- | unaffected |
b2g18 | --- | unaffected |
b2g-v1.1hd | --- | unaffected |
b2g-v1.2 | --- | unaffected |
b2g-v1.3 | --- | unaffected |
People
(Reporter: decoder, Assigned: jandem)
References
Details
(4 keywords, Whiteboard: [jsbugmon:update])
Crash Data
Attachments
(2 files)
995 bytes,
text/plain
|
Details | |
3.68 KB,
patch
|
h4writer
:
review+
|
Details | Diff | Splinter Review |
The following testcase asserts on mozilla-central revision c049cb230d77 (run with --fuzzing-safe --ion-eager): for (var i = 0; i < 3; i++) [,][i] = 3.14159;
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Updated•11 years ago
|
Crash Signature: [@ js::jit::LIRGenerator::visitToDouble]
Keywords: crash
Whiteboard: [jsbugmon:update,bisect]
Reporter | ||
Updated•11 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Reporter | ||
Comment 2•11 years ago
|
||
JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: http://hg.mozilla.org/mozilla-central/rev/1bd9d75fe43b user: Jan de Mooij date: Sat Dec 14 10:57:25 2013 +0100 summary: Bug 949475 - Remove JOF_TYPESET from initializer ops. r=bhackett This iteration took 341.696 seconds to run.
Assignee | ||
Updated•11 years ago
|
Flags: needinfo?(jdemooij)
Reporter | ||
Updated•11 years ago
|
Assignee: general → nobody
QA Contact: general
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(jdemooij)
Assignee | ||
Comment 4•10 years ago
|
||
Yeah this is a regression from bug 949475 part 1, but the underlying bug is older. Before bug 949475, IonBuilder::jsop_newarray would do: types::TemporaryTypeSet::DoubleConversion conversion = bytecodeTypes(pc)->convertDoubleElements(constraints()); Because we only monitored the result of JSOP_NEWARRAY if we had an array with singleton type, bytecodeTypes(pc) would be empty most of the time. NEWARRAY is no longer monitored and we no longer use bytecodeTypes(pc) here. The problem is that the script is Ion-compiled multiple times. The first time we set the CONVERT_DOUBLE_ELEMENTS flag on the template object. The next time we don't set it but it's still set from the last compilation, and we end up trying to convert the magic hole value to double. This patch just clears the flag.
Comment 5•10 years ago
|
||
Comment on attachment 8356090 [details] [diff] [review] Patch Review of attachment 8356090 [details] [diff] [review]: ----------------------------------------------------------------- r+ if you also do the same change to "jit/MCallOptimize.cpp" for inlineArray. So if I correctly understand "templateObject->type()->convertDoubleElements() == AlwaysConvertToDoubles" should always agree with templateObject->getElementsHeader()::AlwaysConvertToDoubles (when we start using it). Since the second is derived from the first. Would it be too hard to adjust the header when the type changes? Because IIUC the type of the templateObject changes and as a result 'AlwaysConvertToDoubles' isn't correct anymore...
Attachment #8356090 -
Flags: review?(hv1989) → review+
Assignee | ||
Comment 6•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/b289ebad63f9 (In reply to Hannes Verschore [:h4writer], pto 13th - 17th of January from comment #5) > So if I correctly understand > "templateObject->type()->convertDoubleElements() == AlwaysConvertToDoubles" > should always agree with > templateObject->getElementsHeader()::AlwaysConvertToDoubles (when we start > using it). Since the second is derived from the first. Would it be too hard > to adjust the header when the type changes? Because IIUC the type of the > templateObject changes and as a result 'AlwaysConvertToDoubles' isn't > correct anymore... Multiple objects can use the same TypeObject, so when a type is added, we don't know the template object with that type.
Updated•10 years ago
|
status-b2g-v1.2:
--- → unaffected
status-b2g-v1.3:
--- → unaffected
status-firefox28:
--- → unaffected
status-firefox29:
--- → affected
status-firefox-esr24:
--- → unaffected
tracking-firefox29:
--- → +
Assignee | ||
Comment 8•10 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #7) > What security rating should this get, jandem? We'll hit a MOZ_ASSUME_UNREACHABLE, not sure what compilers do there in opt builds. If we continue and return true somehow, other code may get confused but probably hard to exploit. Setting sec-moderate.
Flags: needinfo?(jdemooij)
Keywords: sec-moderate
Comment 9•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b289ebad63f9
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-b2g18:
--- → unaffected
status-b2g-v1.1hd:
--- → unaffected
status-firefox27:
--- → unaffected
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Reporter | ||
Updated•10 years ago
|
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 10•10 years ago
|
||
JSBugMon: This bug has been automatically verified fixed.
Updated•9 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•