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

RESOLVED FIXED in mozilla5

Status

()

defect
P1
normal
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: dbaron, Assigned: dbaron)

Tracking

Trunk
mozilla5
All
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 Macaw+, status2.0 .1-fixed)

Details

Attachments

(1 attachment)

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.
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).
Status: NEW → RESOLVED
Closed: 8 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
Attachment #522133 - Flags: review?(joe) → review+
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 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...
Attachment #522133 - Flags: approval2.0?
blocking2.0: ? → Macaw
Comment on attachment 522133 [details] [diff] [review]
patch as landed on mozilla-central

a20
Attachment #522133 - Flags: approval2.0? → approval2.0+
s/a20/Approve for the mozilla2.0 repository, a=dveditz/
You need to log in before you can comment on or make changes to this bug.