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.
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)?
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.
<rdar://problem/39175593>
Zan, Miguel, do either of you have time to look into this one? If not, we'll need to make time.
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.
I guess we could skip it, then
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.
Reopening to attach new patch.
Created attachment 342087 [details] Patch
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
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
Comment on attachment 342087 [details] Patch Ping reviewers
OK, I won't wait for review on this.
Committed r232869: <https://trac.webkit.org/changeset/232869>