Closed Bug 1250311 Opened 8 years ago Closed 8 years ago

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

Categories

(Core :: Graphics: CanvasWebGL, defect)

Product:
Core
Component:
Graphics: CanvasWebGL
Version:
47 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
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)

1250311.diff
9.14 KB, patch
Details | Diff | Splinter Review 
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) — — 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 — — 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
status-firefox-esr45: --- → affected
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.
status-firefox45: --- → affected
status-firefox46: --- → fixed
status-firefox47: affected → fixed
status-firefox-esr38: --- → affected
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

Creator:
Created:
Updated:
Size: