Bug 219340 – REGRESSION(r270185) [GTK] Some webgl failures after multivalue setter refactor

• Component: WebGL
• Status: RESOLVED FIXED

[Lauro Moura]

fast/canvas/webgl/gl-bind-attrib-location-test.html
fast/canvas/webgl/gl-bind-attrib-mapped-names.html
webgl/1.0.3/conformance/attribs/gl-disabled-vertex-attrib.html
webgl/1.0.3/conformance/extensions/angle-instanced-arrays-out-of-bounds.html
webgl/1.0.3/conformance/programs/gl-bind-attrib-location-long-names-test.html
webgl/1.0.3/conformance/programs/gl-bind-attrib-location-test.html
webgl/1.0.3/conformance/rendering/draw-elements-out-of-bounds.html

All with messages like this in stderr (varying the sizes):

Mesa: User error: GL_INVALID_VALUE in glBufferSubData(offset 0 + size 192 > buffer size 48)

Most recent build with errors: https://build.webkit.org/results/GTK-Linux-64-bit-Release-Tests/r270231%20(17200)/results.html

Sample diff from webgl/1.0.3/conformance/programs/gl-bind-attrib-location-test.html

--- /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/webgl/1.0.3/conformance/programs/gl-bind-attrib-location-test-expected.txt
+++ /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/webgl/1.0.3/conformance/programs/gl-bind-attrib-location-test-actual.txt
@@ -1,5 +1,22 @@
 This test runs the WebGL Test listed below in an iframe and reports PASS or FAIL.
 
 Test: ../../resources/webgl_test_files/conformance/programs/gl-bind-attrib-location-test.html
-[ PASS ] All tests passed
+[ 1: PASS ] gl is non-null.
+[ 2: PASS ] getError was expected value: INVALID_OPERATION : bindAttribLocation should return INVALID_OPERATION if name starts with 'gl_'
+[ 3: PASS ] getError was expected value: INVALID_OPERATION : bindAttribLocation should return INVALID_OPERATION if name starts with 'gl_'
+[ 4: PASS ] program linked successfully
+[ 5: PASS ] location of vPosition should be 3
+[ 6: PASS ] location of vColor should be 2
+[ 7: PASS ] First line should be all black
+[ 8: PASS ] Line 15 should be red for at least 10 rgba pixels starting 20 pixels in
+[ 9: PASS ] Last line should be all black
+[ 10: PASS ] program linked successfully
+[ 11: PASS ] location of vPosition should be 3
+[ 12: PASS ] location of vColor should be 0
+[ 13: PASS ] First line should be all black
+[ 14: FAIL ] at (20, 15) expected: 255,0,0,255 was 0,0,0,0
+[ 15: PASS ] Last line should be all black
+[ 16: FAIL ] getError expected: NO_ERROR. Was INVALID_VALUE :
+[ 17: PASS ] successfullyParsed is true
+[ FAIL ] 2 failures reported

[Kimmo Kinnunen]

Created attachment 415006 [details]
Patch

[Kimmo Kinnunen]

Thanks for the investigation.

The GTK EWS bots were green when I submitted the patch that regressed. Do you (or anyone) know why is this?

My mental model is that "Bots green == All tests passed and will most likely pass in future too for this patch."

[Lauro Moura]

(In reply to Kimmo Kinnunen from comment #2)
> Thanks for the investigation.
> 

Thanks for the quick patch

> The GTK EWS bots were green when I submitted the patch that regressed. Do
> you (or anyone) know why is this?
> 
> My mental model is that "Bots green == All tests passed and will most likely
> pass in future too for this patch."

Currently the main EWS queue only runs GTK API tests. We have a GTK Layout tests bot in the UAT queue and we are working to make it stable enough to be moved to the main queue.

I've tested the patch locally and indeed it makes all the tests pass. Just need to update the expectations but I can do it unreviewed once this lands.

[EWS]

Committed r274410: <https://commits.webkit.org/r274410>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 415006 [details].

[Radar WebKit Bug Importer]

<rdar://problem/75424863>