[G45] Possible memory leak with Blender use

[Wolfgang Kufner]

[status as of 2010-09-14]
fixed upstream and in maverick
not fixed in lucid (with current updates)

[report]
This bug was first filed on http://bugs.freedesktop.org/show_bug.cgi?id=24119. Please go there for a detailed description.

It is present in:
7.6.0~git20090817.7c422387-0ubuntu6.
7.6.0~git20090928.6829ef74-0ubuntu1~xup~1
7.7.0~git20090928.d492e7b0-0ubuntu0tormod

[Sven Arvidsson (sa)]

Created an attachment (id=29809)
meminfo before blender use

[Sven Arvidsson (sa)]

Created an attachment (id=29810)
meminfo after blender use

[Wolfgang Kufner (wolfgangkufner)]

Now that is a funny one.

The presence or absence of swap is the key factor in the behavior of this bug.

I have been seeing the following on Mobile 4 [8086:2a42] (rev 07) with mesa 7.6.0~git20090928.6829ef74-0ubuntu1~xup~1:

with 2.4 GByte of swap:
Continuously wiggling the leg of the little fellow as per your instructions I saw periodic bursts of swap use. See attachment periodic_swap_hills.png. The two hills in the screenshot are start less then a minute apart. I also attach the vmstat output that was running the whole time. (The vmstat output ends just after the screenshot was taken but begins several minutes earlier and shows signs of many more such "hills".)

without swap:
I reproduced your bug exactly.

I will next try to reproduce the bug on the other notebook (same graphics, but mesa master from xorg-edgers). I had started out there and seen one of those active memory bursts that go with the swap hills. I did not know what to make of it then because I was looking for the drastic behavior you were describing. That behavior I did not see because I had 4.5GByte swap there. So what I saw there was active memory rising by about 600MB, but then falling again.

[Wolfgang Kufner (wolfgangkufner)]

Created an attachment (id=29945)
periodic_swap_hills.png

[Wolfgang Kufner (wolfgangkufner)]

Created an attachment (id=29946)
vmstat output including the time of the periodic_swap_hills.png screenshot

[Sven Arvidsson (sa)]

That's an interesting observation. My system does not have any swap, which I should have mentioned before.

[Wolfgang Kufner (wolfgangkufner)]

I just reproduced your bug successfully with mesa master on first try after I switched swap off. Everything as you described.

As for mentioning that you have no swap. I saw that in your meminfo attachment. What got me to really notice swap was that I saw that I had it inadvertently off on the second machine I tried to replicate your bug on. After replicating it all of a sudden where I had failed on the other notebook before.

[Sven Arvidsson (sa)]

This is also reproducible with linux 2.6.32-rc1.

Output of cat /sys/kernel/debug/dri/0/gem_objects when this happens:

2253 objects
-566599680 object bytes
5 pinned
15597568 pin bytes
36925440 gtt bytes
134217728 gtt total

Does the negative value for object bytes mean that it wraps around? That would mean that it does use quite a lot of memory...

[Wolfgang Kufner (wolfgangkufner)]

I just replicated this bug with the even older 7.6.0~git20090817.7c422387-0ubuntu6 that is currently in ubuntu karmic.
Basically the same behaviour though I did not see OOM killer messages, but the desktop became unresponsive with swap off.
With swap on I saw those hills again though it took me about 3 minutes or so to trigger the bug. That went faster last time. It might not always be easy to get the buggy behaviour.

[Wolfgang Kufner (wolfgangkufner)]

This bug was first filed on http://bugs.freedesktop.org/show_bug.cgi?id=24119. Please go there for a detailed description.

It is present in:
7.6.0~git20090817.7c422387-0ubuntu6.
7.6.0~git20090928.6829ef74-0ubuntu1~xup~1
7.7.0~git20090928.d492e7b0-0ubuntu0tormod

[Tormod Volden (tormodvolden)]

Thanks for your report, and especially for checking the different versions!

[Eric Anholt (eric-anholt)]

Could you retest with this in mesa:

commit 49fbdd18ed738feaf73b7faba4d3577cd9cc3e59
Author: Eric Anholt <email address hidden>
Date: Thu Feb 12 03:54:58 2009 -0800

    i965: Fix massive memory allocation for streaming texture usage.

    Once we've freed a miptree, we won't see any more state cache requests
    that would hit the things that pointed at it until we've let the miptree
    get released back into the BO cache to be reused. By leaving those
    surface state and binding table pointers that pointed at it around, we
    would end up with up to (500 * texture size) in memory uselessly consumed
    by the state cache.

    Bug #20057
    Bug #23530

[Bryce Harrington (bryce)]

Hi wolfgangkufner,

Please attach the output of `lspci -vvnn` and `dmesg`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you're using a custom /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Sven Arvidsson (sa)]

Unfortunately no, I can still reproduce it with 49fbdd18ed738feaf73b7faba4d3577cd9cc3e59

[Eric Anholt (eric-anholt)]

*** Bug 26461 has been marked as a duplicate of this bug. ***

[Bryce Harrington (bryce)]

[This is an automatic notification.]

Hi Wolfgang,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 438964

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 438964 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/438964

[Eric Anholt (eric-anholt)]

What it's not:
- bo reuse
- leaking of texture objects or images
- texture tiling overallocation

INTEL_DEBUG=buf suggests that we've got a ton of SS_SURFACE/SS_SURF_BIND laying around. Maybe that broke.

[Eric Anholt (eric-anholt)]

commit ce914fff0817cb3c25a2d715f8435c6b6d6fbcdd
Author: Eric Anholt <email address hidden>
Date: Tue May 4 22:02:18 2010 -0700

    i965: When an RB gets a new region, clear the old from the state cache.

    This prevents memory usage explosion in blender due to the state cache
    hanging on to old fake frontbuffer regions. Sigh at blender still
    using frontbuffer rendering.

    Bug #24119.

[Sven Arvidsson (sa)]

Awesome! You rock! :)

[Bryce Harrington (bryce)]

[Resetting to incomplete since we need a response from the original reporter on this].

[Wolfgang Kufner (wolfgangkufner)]

As the upstream report shows the bug was fixed with commit ce914fff0817cb3c25a2d715f8435c6b6d6fbcdd by Eric Anholt on Tue May 4 22:02:18 2010 -0700.

I have tried this out with current stable blender (2.49b):
maverick is fixed
lucid is _not_ fixed

[Wolfgang Kufner (wolfgangkufner)]

Since this is fixed in maverick (although not in lucid) I think this should be closed. Closing...