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

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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;");

Comment 1

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

Comment 2

[Christian Holler (:decoder)]

Marking sec-critical due to infer failure.

Comment 3

[Matt Wobensmith [:mwobensmith][:matt:]]

decoder, is there a bisect planned for this bug?

Comment 4

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision bc7deafdac4b).

Comment 5

[Christian Holler (:decoder)]

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.

Comment 6

[Christian Holler (:decoder)]

(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!

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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?

Comment 8

[Brian Hackett [Laid off!]]

Attachment: patch

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.

Comment 9

[Brian Hackett [Laid off!]]

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

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8488262 [details] [diff] [review]
patch

Has auto-approval for the b2g release branches once it's approved for the other ones.

Comment 11

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8488262 [details] [diff] [review]
patch

Many approvals given!

Comment 12

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d803279cf506

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/d803279cf506

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/464e58c74841
https://hg.mozilla.org/releases/mozilla-beta/rev/025117f71163
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e02fe140c0d5
https://hg.mozilla.org/releases/mozilla-esr31/rev/0d982ed33ee4
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/a7f7eaf3f682

Comment 15

[Matt Wobensmith [:mwobensmith][:matt:]]

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.

Comment 16

[Christian Holler (:decoder)]

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.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/e02fe140c0d5

Comment 18

[Matt Wobensmith [:mwobensmith][:matt:]]

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.

Comment 19

[Christian Holler (:decoder)]

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).

Comment 20

[Matt Wobensmith [:mwobensmith][:matt:]]

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.