Closed Bug 1250311 Opened 9 years ago Closed 9 years ago

Beta and Release and esr38 and esr45 Permafailing bufferSubData.html | bufferSubData - expected FAIL since the mesa upgrade

Categories

(Core :: Graphics: CanvasWebGL, defect)

47 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox45 --- fixed
firefox46 --- unaffected
firefox47 --- unaffected
firefox-esr38 --- affected
firefox-esr45 --- fixed

People

(Reporter: KWierso, Assigned: jgraham)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

These have been permafailing on all linux platforms since the libmesa upgrade happened: https://treeherder.mozilla.org/logviewer.html#?job_id=811868&repo=mozilla-beta
Assignee: nobody → jgilbert
Actually, this is web-platform-tests.
Assignee: jgilbert → james
The fun thing is, there are two possibilities: * the only reason these tests "correctly" continue to fail on aurora and trunk is because we are using GTK+3 there, and it introduced a new failure which doesn't exist with GTK+2 on top of the prior mesa failure, so we still fail on trunk even though the mesa failure is gone, but on beta and release where we've gone back to GTK+2 we don't fail * we do something !RELEASE_BUILD which causes us to fail, so when we hit beta we unexpectedly pass
Summary: Beta Permafailing bufferSubData.html | bufferSubData - expected FAIL since the mesa upgrade → Beta and Release Permafailing bufferSubData.html | bufferSubData - expected FAIL since the mesa upgrade
Summary: Beta and Release Permafailing bufferSubData.html | bufferSubData - expected FAIL since the mesa upgrade → Beta and Release and esr38 Permafailing bufferSubData.html | bufferSubData - expected FAIL since the mesa upgrade
Ah, if it were a matter of RELEASE_BUILD causing them to start passing, then Ryan's aurora-as-beta simulation try pushes would show unexpected passes, and they do not, so it must be GTK+2.
james, do you have any eta fixing this ?
Flags: needinfo?(james)
Attached patch 1250311.diff (obsolete) (deleted) — Splinter Review
Does this do what you want? (sorry I didn't do this earlier; I didn't realise you were waiting for me to create an updated metadata file).
Flags: needinfo?(james)
Attachment #8724712 - Flags: feedback?(cbook)
Comment on attachment 8724712 [details] [diff] [review] 1250311.diff yeah fomr a quick look (also not an expert here) it does look ok :)
Attachment #8724712 - Flags: feedback?(cbook) → feedback+
Attached patch 1250311.diff (deleted) — Splinter Review
Attached a version with a better commit message. Tomcat, are you OK to check this in on various branches as needed?
Attachment #8724712 - Attachment is obsolete: true
Keywords: checkin-needed
Summary: Beta and Release and esr38 Permafailing bufferSubData.html | bufferSubData - expected FAIL since the mesa upgrade → Beta and Release and esr38 and esr45 Permafailing bufferSubData.html | bufferSubData - expected FAIL since the mesa upgrade
(In reply to Carsten Book [:Tomcat] from comment #14) > https://hg.mozilla.org/releases/mozilla-beta/rev/cc7623105377 > https://hg.mozilla.org/releases/mozilla-release/rev/20962170ebea This appears to have been an incomplete fix. On Gecko 45 repos, linux32 debug and linux64 opt/debug are still failing.
46 and 47 aren't fixed - they are unaffected iff we don't punt on shipping GTK+3 again, and suddenly affected if we do. Them being fixed would imply that we landed a patch that did - if not debug and (os == "linux") and (version == "Ubuntu 12.04") and (processor == "x86") and (bits == 32): FAIL + if not debug and (os == "linux") and (version == "Ubuntu 12.04") and (processor == "x86") and (bits == 32) and (gtk == "3"): FAIL for all four of 32/64 and opt/debug plus whatever code wherever to make gtk as a condition work.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: