Closed
Bug 799907
Opened 13 years ago
Closed 13 years ago
IonMonkey: Assertion failure: mir->type() == MIRType_Value, at ../ion/shared/Lowering-shared-inl.h:413 or Crash [@ js::ion::LinearScanAllocator::populateSafepoints]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
mozilla19
Tracking | Status | |
---|---|---|
firefox18 | --- | affected |
firefox19 | --- | fixed |
firefox-esr10 | --- | unaffected |
firefox-esr17 | --- | unaffected |
b2g18 | --- | unaffected |
People
(Reporter: decoder, Assigned: dvander)
References
Details
(4 keywords, Whiteboard: [jsbugmon:update][ion:p1][adv-main19+])
Crash Data
Attachments
(2 files)
2.22 KB,
application/javascript
|
Details | |
1.18 KB,
patch
|
djvj
:
review+
|
Details | Diff | Splinter Review |
The attached testcase asserts on mozilla-central revision ec10630b1a54 (run with --ion-eager).
Reporter | ||
Comment 1•13 years ago
|
||
Crash trace from opt-build:
==32163== Invalid read of size 4
==32163== at 0x83890CA: js::ion::LinearScanAllocator::populateSafepoints() (LIR.h:90)
==32163== by 0x8345128: js::ion::CompileBackEnd(js::ion::IonBuilder*) (Ion.cpp:881)
==32163== by 0x92C0B07: ???
==32163== by 0x92BC087: ???
==32163== Address 0x1c is not stack'd, malloc'd or (recently) free'd
S-s due to GC-relatedness and fragile test.
Blocks: IonFuzz
Crash Signature: [@ js::ion::LinearScanAllocator::populateSafepoints]
Keywords: crash
Summary: Assertion failure: mir->type() == MIRType_Value, at ../ion/shared/Lowering-shared-inl.h:413 or Crash [@ js::ion::LinearScanAllocator::populateSafepoints] → IonMonkey: Assertion failure: mir->type() == MIRType_Value, at ../ion/shared/Lowering-shared-inl.h:413 or Crash [@ js::ion::LinearScanAllocator::populateSafepoints]
Whiteboard: [jsbugmon:update,bisect]
Reporter | ||
Updated•13 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Reporter | ||
Comment 2•13 years ago
|
||
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:
The first bad revision is:
changeset: 109322:825de541f566
user: Kannan Vijayan
date: Fri Oct 05 00:28:36 2012 -0400
summary: Bug 786126 - part 3 - Allow null/undefined in typeset of target object of GetProp ICs. (r=sstangl)
This iteration took 91.551 seconds to run.
![]() |
Assignee | |
Updated•13 years ago
|
Whiteboard: [jsbugmon:update] → [jsbugmon:update][ion:p1]
![]() |
Assignee | |
Comment 3•13 years ago
|
||
IonMonkey's type information can sometimes be more accurate than TI's; in this case TI's typeset said "value" but Ion said "Object", so the explicit unbox was asserting. GetPropertyCache has an unboxing type policy though, so we can rely on that working instead.
![]() |
Assignee | |
Updated•13 years ago
|
Attachment #670163 -
Flags: review? → review?(kvijayan)
Updated•13 years ago
|
Attachment #670163 -
Flags: review?(kvijayan) → review+
![]() |
Assignee | |
Comment 4•13 years ago
|
||
Comment 5•13 years ago
|
||
(In reply to David Anderson [:dvander] from comment #3)
> Created attachment 670163 [details] [diff] [review]
> fix
>
> IonMonkey's type information can sometimes be more accurate than TI's; in
> this case TI's typeset said "value" but Ion said "Object", so the explicit
> unbox was asserting. GetPropertyCache has an unboxing type policy though, so
> we can rely on that working instead.
Another problem here is that we're looking at obj->type() to determine the type of a MIR node -- when it is actually a redundant MPhi of (Object, Object), but during the IonBuilder phase it is typed as MIRType_Value. It's another one of those situations where we're looking at the MIR in order to build the MIR.
It's safe to just remove the erroneous condition, since it's redundant.
Comment 6•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
status-firefox18:
--- → affected
status-firefox19:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Reporter | ||
Updated•13 years ago
|
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 7•13 years ago
|
||
JSBugMon: This bug has been automatically verified fixed.
Updated•13 years ago
|
status-firefox-esr10:
--- → unaffected
Comment 8•12 years ago
|
||
crash automation hit this on Aurora/18 on Windows/Linux at
https://docs.google.com/presentation/d/1FC1pyFCnK_8-2tAcPGmVUkWDginw_Okks_x0kL_OVG0/edit#slide=id.g20e781bb_0_26
Updated•12 years ago
|
status-firefox-esr17:
--- → unaffected
![]() |
Assignee | |
Updated•12 years ago
|
status-b2g18:
--- → unaffected
Comment 10•12 years ago
|
||
This never got a security rating. Can someone suggest one?
Whiteboard: [jsbugmon:update][ion:p1] → [jsbugmon:update][ion:p1][adv-main19+]
![]() |
Assignee | |
Comment 11•12 years ago
|
||
This one is not really clear, it's either not exploitable at all or it's sg:critical. I'd just go with sg:critical.
Updated•12 years ago
|
Keywords: sec-critical
Updated•11 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•