I've been trying to get the webgl mochitests running on QR builds. Right now in automation they mostly blow up because they end up OOMing. I can reproduce the leak locally, by running: ./mach mochitest --subsuite webgl and watching the memory usage over time. I was able to make a DMD-enabled [1] build and get some DMD dumps while this was happening, and it indicated that we were leaking textures (see attachment). I added some more logging around this and I believe the problem is that WR uses TexturePages to hold the individual textures, and it allocates a new texture page when it runs out of room on the previous page. However if the previous pages are then freed up, it never seems to go back and use them, or free them. So they just sit there holding on to a lot of memory. I think that this memory might not even be freed on shutdown. [1] https://developer.mozilla.org/en-US/docs/Mozilla/Performance/DMD

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #0) > However if the > previous pages are then freed up, it never seems to go back and use them, or > free them. This sentence is poorly worded. By "freed up" I mean all the little textures inside it are removed. And by "free them" I mean deallocated.

Dzmitry landed a fix for this in webrender. The try push at [1] has a version of webrender with his patches, and the webgl/media mochitests are running quite well so far. [1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ef07d2d85f6c8e3e9a2c3261370e08d8574224b

This is fixed in upstream WR, so closing.