595352 - Intermittent orange: webGLArrays.html test timing out, apparently due to GC

Status: RESOLVED DUPLICATE of bug 698856

(Core :: Graphics: CanvasWebGL, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

I'm watching the mochitest from bug 582053 on the tryservers. I have intermittents timeout in this test page:

    more/conformance/webGLArrays.html

I don't see anything in this test page explaining a timeout. But in the mochitest log, there is:

--- WebGL context destroyed: 0x320c2c00
--- WebGL context destroyed: 0x2f838e00
--- WebGL context destroyed: 0x1b131c00
--- WebGL context destroyed: 0x3473e800
--- WebGL context destroyed: 0x2d272000
--- WebGL context destroyed: 0x2dcada00
--- WebGL context destroyed: 0x30bac200
--- WebGL context destroyed: 0x32b89400
--- WebGL context destroyed: 0x237ae200
--- WebGL context destroyed: 0x2d3e8600
--- WebGL context destroyed: 0x237e9a00
--- WebGL context destroyed: 0x2fe0a000
++DOMWINDOW == 17 (0x23aa9af8) [serial = 829] [outer = 0x1c574440]
34339 ERROR TEST-UNEXPECTED-FAIL | /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html | Unexpected timeout in this test page (URL: more/conformance/webGLArrays.html)
WebGL test error: test page timeout: more/conformance/webGLArrays.html


So we see that a lot of old WebGL contexts are getting destroyed at once and that is what made webGLArrays.html time out.

Now you might wonder: why is it, then, that it's always with webGLArrays.html that it's happening?

The answer might come from a look at the list of tests that the harness reads, executing tests in this order (this is in more/00_testFIXME_list.txt):

[snip...]
conformance/getContext.html
conformance/methods.html
conformance/quickCheckAPI.html
conformance/quickCheckAPIBadArgs.html
conformance/webGLArrays.html
functions/bindBuffer.html
[snip...]

Here we see that webGLArrays.html comes right after quickCheckAPIBadArgs.html. But quickCheckAPIBadArgs.html is a memory-intensive test which causes buffers of various random sizes to be allocated. So that would explain why GC happens at that point.

What might be solutions?

 - ideally, is there a way that I can force GC from the mochitest itself (that is from the JS)? (Sorry I asked this already and forgot the answer).

 - alternatively, we can increase the timeout. There should be no timeout anyway in these tests.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Call garbage collector to prevent timeouts

This patch calls the garbage collector manually, before the start of every test page. Seems to work nicely here, will ask for review once it's run on the tryserver...

Comment 2

[Kelsey Gilbert [:jgilbert]]

We fixed this a while ago, but I can't find the bug. Can you dupe this, bjacob?

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Dupe of bug 698856 found by hg annotate.