945632 - Memory leak (gfx/heap-textures increases forever) with OpenGL layers on Linux

Status: NEW

(Core :: Graphics: Layers, defect)

Description

[Nick Cameron [:nrc]]

dbaron reported a possible memory leak on Linux with OMTC - memory used rising to 5GB which didn't clear until shutdown. I could not repro with some browsing and leaving Firefox open for most of the day - vsize stayed pretty constant at 1.5GB with no significant use by gfx.

Even though HWA/OMTC is not really supported on Linux, this is probably worth investigating since (afaik) we don't do anything on Linux we don't also do elsewhere, so the memory leak might manifest elsewhere too.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

OK, I'll flip the pref again and see what happens.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So, in the session that I noticed this leak in, I was doing a lot of browsing of maps (which have a lot of images).

And, in particular, with both the layers.acceleration.force-enabled and layers.offmainthreadcomposition.enabled pref enabled, if I load https://www.mapbox.com/bites/00001/#2/15.0/30.0 and then pan and zoom around a lot, and then look at about:memory, the gfx/heap-textures number in about:memory just keep going up.  (I get get it up to 100MB in less than a minute.)  I think heap-unclassified is increasing along with it.

If I leave layers.acceleration.force-enabled enabled and disable layers.offmainthreadcomposition.enabled then I still see the problem, but if I disable both it seems like it goes away, so it seems like it's specific to GL on Linux rather than to OMTC on Linux.

That said, I did the testing relatively quickly, so it's possible some other number would have increased in the non-GL setup.  It's probably worth repeating a little more carefully, perhaps with a testcase that shows the memory increase without a few minutes of panning around.

Comment 3

[Nick Cameron [:nrc]]

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #2)
> So, in the session that I noticed this leak in, I was doing a lot of
> browsing of maps (which have a lot of images).
> 
> And, in particular, with both the layers.acceleration.force-enabled and
> layers.offmainthreadcomposition.enabled pref enabled, if I load
> https://www.mapbox.com/bites/00001/#2/15.0/30.0 and then pan and zoom around
> a lot, and then look at about:memory, the gfx/heap-textures number in
> about:memory just keep going up.  (I get get it up to 100MB in less than a
> minute.)  I think heap-unclassified is increasing along with it.
> 
> If I leave layers.acceleration.force-enabled enabled and disable
> layers.offmainthreadcomposition.enabled then I still see the problem, but if
> I disable both it seems like it goes away, so it seems like it's specific to
> GL on Linux rather than to OMTC on Linux.
> 
> That said, I did the testing relatively quickly, so it's possible some other
> number would have increased in the non-GL setup.  It's probably worth
> repeating a little more carefully, perhaps with a testcase that shows the
> memory increase without a few minutes of panning around.

Great, thanks for the extra info. That it is gfx/heap-textures that increases is very useful - it means we are leaking memory images (like shmem, but for sharing between threads in a single process). (It also makes me happy because I only landed that memory reporter a couple of weeks ago).

If it is a recent nightly, then there is no difference if layers.offmainthreadcomposition.enabled is set or not - you will always get OMTC with HWA because there is no more MT OpenGL.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The original observation was probably a 1-2 week old debug build (and I really did think turning off OMTC fixed the problem, since I did a good bit of browsing the same maps after turning it off), but the specific tests I did today were on a nightly from yesterday (2013-12-02-03-02-01).

Comment 5

[Nick Cameron [:nrc]]

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #4)
> The original observation was probably a 1-2 week old debug build (and I
> really did think turning off OMTC fixed the problem, since I did a good bit
> of browsing the same maps after turning it off), but the specific tests I
> did today were on a nightly from yesterday (2013-12-02-03-02-01).

That makes sense - a week ago we still had main thread GL, but by yesterday it was gone.

Comment 6

[Nick Cameron [:nrc]]

I reproduced the leak and confirmed that we are leaking memory for memory images via DeprecatedTexture*Shmem. Given that the non-deprecated versions are in use or will be shortly everywhere, I wonder if this is worth fixing for now.

Comment 7

[Nick Cameron [:nrc]]

My reasoning is we don't need to fix this because we have new textures for shmem/memory everywhere except Windows, where we will have them very soon. Is that assumption correct? Is there any other reason to investigate this further?

Comment 8

[Nick Cameron [:nrc]]

Confirmed that setting layers.use-deprecated-textures to false fixes the leak.

Comment 9

[Nick Cameron [:nrc]]

Attachment: Assert we don't leak in one specific way

I'm pretty sure we are not doing this, but it is nice to assert it. I'm sure there are other ways we could leak but don't have asserts, but I did this one during my investigation, so I figure I should land it.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Nick Cameron [:nrc] from comment #7)
> My reasoning is we don't need to fix this because we have new textures for
> shmem/memory everywhere except Windows, where we will have them very soon.
> Is that assumption correct? Is there any other reason to investigate this
> further?

I'm OK with not fixing this, if it goes away when the non-deprecate textures are turned back off. If this is a regression, then my opinion changes :)  Either way, if this goes away when we do new textures, lets have a dependency recorded in this bug - which bug should it depend on?

Comment 11

[Andreas Gal :gal]

Lets delete the bug with the deprecated code :) If that gets stalled we can always jump back on this and fix it.

Comment 12

[Nicolas Silva [:nical]]

filed bug 946200 for Linux, new textures on Windows are coming very soon.

Comment 13

[Nick Cameron [:nrc]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8b33af450fc6

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Apparently we leak our buffers. A lot. Backed out. Please run this through Try before landing this again.
https://hg.mozilla.org/integration/mozilla-inbound/rev/8ee4f2722437

One of many examples:
https://tbpl.mozilla.org/php/getParsedLog.php?id=31466457&tree=Mozilla-Inbound

Comment 15

[Nick Cameron [:nrc]]

try push: https://tbpl.mozilla.org/?tree=Try&rev=d6e816067d8c

Comment 16

[Nick Cameron [:nrc]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5204feef4698

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5204feef4698

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For the record, I don't hit the assertion.  But I think things may still be pretty leaky (see data (!!) in bug 969898).

Comment 19

[Milan Sreckovic [:milan] (needinfo for best results)]

Maybe we should make it a gfxCriticalError+MOZ_CRASH, monitor if we catch any.