Bug 181659 – [WPE][GTK][WebGL] Layout test fast/canvas/webgl/simulated-vertexAttrib0-invalid-indicies.html is failing

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Michael Catanzaro]

Layout test fast/canvas/webgl/simulated-vertexAttrib0-invalid-indicies.html has been failing on the GTK release bot since it was added in r226916 "[WebGL] Simulated vertexAttrib0 can sometimes cause OUT_OF_MEMORY errors":

--- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/canvas/webgl/simulated-vertexAttrib0-invalid-indicies-expected.txt
+++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/canvas/webgl/simulated-vertexAttrib0-invalid-indicies-actual.txt
@@ -1,5 +1,4 @@
 CONSOLE MESSAGE: line 49: WebGL: INVALID_OPERATION: drawElements: attempt to access out of bounds arrays
-CONSOLE MESSAGE: line 59: WebGL: INVALID_OPERATION: drawElements: unable to simulate vertexAttrib0 array
 PASS: MAX_UINT index was unable to be simulated
-PASS: Huge index was unable to be simulated
+FAIL: Huge index did not fail validation

Updating expectations accordingly.

[Michael Catanzaro]

I'm going to give it a failure expectation, but it's notable because this test is an example of the API call *not* failing, so not sure if this is really a problem or not. Maybe the test should just be skipped instead, or marked as expected expected fail (i.e. bug closed, expectation moved to the top of the file)?

[Michael Catanzaro]

At the advice of Carlos Lopez, I ran:

$ run-webkit-tests --gtk --debug --display-server=wayland fast/canvas/webgl/simulated-vertexAttrib0-invalid-indicies.html

to run the layout test without swrast. The test consumed ~11 GB of memory and timed out. I'm guessing the fix is somehow incomplete on our platform.

This is CVE-2018-4130 on the Safari 11.1 security advisory. I'm going to omit it from our upcoming advisory. When fixing this, please be sure to remind me to add it to a future advisory, if necessary.

[Radar WebKit Bug Importer]

<rdar://problem/39175593>

[Michael Catanzaro]

Zan, Miguel, do either of you have time to look into this one? If not, we'll need to make time.

[Miguel Gomez]

The test fails because wk expects an out of memory error coming from opengl when trying to allocate the almost 6GB of memory requested to glBufferData, but that error is not happening because the allocation succeeds.

The bot uses mesa with an intel driver, and the main memory is shared with the video memory, which means that we can request as much memory as there's in the system. In that case, the system will slow down and the test will timeout, but the allocation will still work.

I guess this test makes sense in systems with dedicated video memory, when the amount of memory requested is bigger than the video memory available, but I don't think it makes sense with the wide range of hardware we deal with. IMO the best thing to do with this is skip the test or keep it as a failure.

[Michael Catanzaro]

I guess we could skip it, then

[Michael Catanzaro]

I think it could be victim to the memory pressure limit, if not now then in the future, so I'd favor Skip instead of expected failure.

[Michael Catanzaro]

Reopening to attach new patch.

[Michael Catanzaro]

Created attachment 342087 [details]
Patch

[EWS Watchlist]

Comment on attachment 342087 [details]
Patch

Attachment 342087 [details] did not pass win-ews (win):
Output: http://webkit-queues.webkit.org/results/8045964

New failing tests:
http/tests/security/canvas-remote-read-remote-video-localhost.html

[EWS Watchlist]

Created attachment 342118 [details]
Archive of layout-test-results from ews206 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews206  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Michael Catanzaro]

Comment on attachment 342087 [details]
Patch

Ping reviewers

[Michael Catanzaro]

OK, I won't wait for review on this.

[Michael Catanzaro]

Committed r232869: <https://trac.webkit.org/changeset/232869>