Closed Bug 1061600 Opened 6 years ago Closed 5 years ago

Assertion failure: [infer failure] Missing type in object [0x7f6dbe642938] : float, at jsinfer.cpp:288

Categories

(Core :: JavaScript Engine, defect, critical)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla35
Tracking Status
firefox32 --- wontfix
firefox33 + fixed
firefox34 + fixed
firefox35 + fixed
firefox-esr31 33+ fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed
b2g-v2.0M --- fixed
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed

People

(Reporter: decoder, Assigned: bhackett1024)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [jsbugmon:][adv-main33+][adv-esr31.2+][b2g-adv-main2.2-])

Attachments

(2 files)

The following testcase asserts on mozilla-central revision c360f3d1c00d (run with --fuzzing-safe --no-threads --ion-eager):


setJitCompilerOption("baseline.usecount.trigger", 10);
function newFunc(x) { new Function(x)(); };
newFunc('\
function test(m) {\
  do {\
    if (m = arr[0]) break;\
    m >>=  0;\
  }\
  while (0);\
  arr[("")] = m;\
}\
arr = new Float64Array(2);\
for(var i=0; i<200; i++)\
  test(0);\
');
Object.preventExtensions(this);
eval("var x;");
Marking sec-critical due to infer failure.
Keywords: sec-critical
Whiteboard: [jsbugmon:update,bisect]
decoder, is there a bisect planned for this bug?
Flags: needinfo?(choller)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update,bisect,ignore]
JSBugMon: The testcase found in this bug no longer reproduces (tried revision bc7deafdac4b).
Flags: needinfo?(choller)
Whiteboard: [jsbugmon:update,bisect,ignore] → [jsbugmon:bisect,bisectfix]
Whiteboard: [jsbugmon:bisect,bisectfix] → [jsbugmon:bisect]
JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/64203c2e785d
user:        Nicolas B. Pierron
date:        Wed Sep 10 19:11:20 2014 +0200
summary:     Bug 1063816 - Rename useCount to warmUpCounter. r=h4writer

This iteration took 340.992 seconds to run.
(In reply to Christian Holler (:decoder) from comment #5)
> JSBugMon: Fix Bisection requested, result:
> autoBisect shows this is probably related to the following changeset:
> 
> The first good revision is:
> changeset:   https://hg.mozilla.org/mozilla-central/rev/64203c2e785d
> user:        Nicolas B. Pierron
> date:        Wed Sep 10 19:11:20 2014 +0200
> summary:     Bug 1063816 - Rename useCount to warmUpCounter. r=h4writer
> 
> This iteration took 340.992 seconds to run.


That's likely unrelated, the bug might be intermittent.

Gary, can you run a manual bisect on this with your magic for intermittent bugs? Thanks!
Flags: needinfo?(gary)
So I dug into this - the bug wasn't intermittent, it just went back very far (back to the days of --ion-parallel-compile=off), so I tweaked the CLI flags.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/78fa90a29c43
user:        Brian Hackett
date:        Tue Mar 04 12:42:08 2014 -0700
summary:     Bug 695438 - Make typed arrays native objects, allow adding new named properties, r=luke.

Brian, is bug 695438 a likely regressor?
Blocks: 695438
Flags: needinfo?(gary) → needinfo?(bhackett1024)
Keywords: regression
Whiteboard: [jsbugmon:bisect] → [jsbugmon:]
Attached patch patchSplinter Review
Hmm, PropertyWriteNeedsTypeBarrier has a special exclusion for typed array objects which predates the point when they could have named properties added, and I neglected to update this as part of bug 695438.
Assignee: nobody → bhackett1024
Attachment #8488262 - Flags: review?(jdemooij)
Flags: needinfo?(bhackett1024)
Attachment #8488262 - Flags: review?(jdemooij) → review+
Comment on attachment 8488262 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]: bug 695438
[User impact if declined]: potential exploit
[Describe test coverage new/current, TBPL]: none
[Risks and why]: none

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

Pretty difficult, would require deep knowledge of the JIT and type inference.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

no

Which older supported branches are affected by this flaw?

30+

If not all supported branches, which bug introduced the flaw?

bug 695438

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

trivial

How likely is this patch to cause regressions; how much testing does it need?

none
Attachment #8488262 - Flags: sec-approval?
Attachment #8488262 - Flags: approval-mozilla-esr31?
Attachment #8488262 - Flags: approval-mozilla-beta?
Attachment #8488262 - Flags: approval-mozilla-b2g32?
Attachment #8488262 - Flags: approval-mozilla-b2g30?
Attachment #8488262 - Flags: approval-mozilla-aurora?
Comment on attachment 8488262 [details] [diff] [review]
patch

Has auto-approval for the b2g release branches once it's approved for the other ones.
Attachment #8488262 - Flags: approval-mozilla-b2g32?
Attachment #8488262 - Flags: approval-mozilla-b2g30?
Comment on attachment 8488262 [details] [diff] [review]
patch

Many approvals given!
Attachment #8488262 - Flags: sec-approval?
Attachment #8488262 - Flags: sec-approval+
Attachment #8488262 - Flags: approval-mozilla-esr31?
Attachment #8488262 - Flags: approval-mozilla-esr31+
Attachment #8488262 - Flags: approval-mozilla-beta?
Attachment #8488262 - Flags: approval-mozilla-beta+
Attachment #8488262 - Flags: approval-mozilla-aurora?
Attachment #8488262 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/d803279cf506
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Hi decoder - I'm trying to verify this fixed on Fx31.1.1esr. This branch does not appear to support the --no-threads flag. If you have another way to run this test case, let me know. If not, I'll just skip it and move on to other branches. Thanks.
Flags: needinfo?(choller)
In older versions, --no-threads is roughly equivalent to *building* with --disable-threadsafe. They replaced that configure flag with the --no-threads runtime flag to unify the builds.
Flags: needinfo?(choller)
Whiteboard: [jsbugmon:] → [jsbugmon:][adv-main33+][adv-esr31.2+]
Hmmm... can't reproduce the assert in any of the branches, going from Gary's bisect in comment 7 through the fix date. 

Decoder, if you can verify that this is fixed for you in Fx33, that would be helpful.
You should try with --ion-parallel-compile=off as gkw mentioned in comment 7. If the bug still doesn't reproduce on the branches, then the test might just not work there. We can't easily verify it then (even if older branches are affected, the test in comment 0 might not be able to trigger the failure there).
Thanks Decoder. Tried that. Still no assert for me, but on the bright side, no assert. :)

I won't be able to mark this as verified (since I can't reproduce the problem) but I've confirmed that release builds of Fx33 appear fine. So, it's better than nothing.
Flags: qe-verify-
Whiteboard: [jsbugmon:][adv-main33+][adv-esr31.2+] → [jsbugmon:][adv-main33+][adv-esr31.2+][b2g-adv-main2.2-]
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.