645376 - [Mac only] when there are graphics blocklist entries, what is blocked depends on uninitialized variable on stack

Status: RESOLVED FIXED

(Core :: Graphics, defect, P1)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The automated blocklist refresh just landed again, causing the 10.6 Mac debug mochitest-1 to turn permaorange with:

36162 ERROR TEST-UNEXPECTED-FAIL | /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html | Can't create a WebGL context

I believe the underlying problem is that the Mac implementation of GfxInfo::GetFeatureStatusImpl returns success without assigning to aStatus, which leaves GfxInfoBase::EvaluateDownloadedBlacklist deciding what to do based on its uninitialized |status| variable on the stack.


In other words, once we have gfx entries in the blacklist, whether gfx features are blocked on mac depends on an uninitialized stack variable.

Now, uninitialized stack variables might be somewhat deterministic based on compilation.  But this is still bad.


I'm going to land the obvious fix on trunk without review to get the tree green again, but it'll need to get reviewed, and also probably landed on branch.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://hg.mozilla.org/mozilla-central/rev/497e9a9d5982

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch as landed on mozilla-central

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And for the record, the changeset that started the permaorange was http://hg.mozilla.org/mozilla-central/rev/5c9d01016ee6 (note the gfx stuff at the bottom).

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And the bug was introduced in http://hg.mozilla.org/mozilla-central/rev/aa85b04aa9ef

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And for the record, I think we only get in trouble if the uninitialized 32-bit integer happens to have the value 2, 3, 4, or 5.  (2 yields one behavior; 3, 4, and 5 yield another.)  So I guess we happened to hit one of those reliably on Mac debug builds.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 522133 [details] [diff] [review]
patch as landed on mozilla-central

I wonder if approval2.0? is what we're using for the .x release...

Comment 7

[Daniel Veditz [:dveditz]]

Comment on attachment 522133 [details] [diff] [review]
patch as landed on mozilla-central

a20

Comment 8

[Daniel Veditz [:dveditz]]

s/a20/Approve for the mozilla2.0 repository, a=dveditz/

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://hg.mozilla.org/releases/mozilla-2.0/rev/03c2f6c1eb3c