registry team mailing list archive

[Bug Watch Updater <438964@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 16 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=24119.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2009-09-23T10:56:41+00:00 Sven Arvidsson wrote:

Created an attachment (id=29808)
blender model

I think I have stumbled upon a memory leak somewhere which happens
during a certain operation in Blender.

When armature is moved around in pose mode in Blender, the system
quickly becomes unresponsive, wants to swap, and the OOM killer kicks
in.

Whatever is using all memory does not seem to show up in top output but
I very much doubt it's Blender since this is a very simple model, and
it's well behaved if software rendering is forced.

Examining /proc/meminfo does show a huge spike in Active memory (see
attched for full output).

I'm not sure how to go on investigation this so I'm attaching the .blend
file of the model and hope it's easy to reproduce. Simply load the
model, press G on the keyboard and move the selected leg around with the
mouse. On my system (4GB of RAM) it takes about 15-20 seconds of
movement before the system is becoming unresponsive.

System environment:
-- chipset: G45 / ICH10R
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- Machine or mobo model: Asus P5Q-EM
-- Display connector: DVI
-- KMS: enabled
-- xf86-video-intel: efbcf29dd1a1ca058b7a2a93f0685102c06c9369
-- xserver: 1.6.3.901
-- mesa: de25f82067bca5231fb968190f6c12cb517d62ff
-- drm: 67e4172394a88d4922fb8d9c7c3d96ce7e02c5a6
-- kernel: 2.6.31

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/0

------------------------------------------------------------------------
On 2009-09-23T10:57:15+00:00 Sven Arvidsson wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/1

------------------------------------------------------------------------
On 2009-09-23T10:57:33+00:00 Sven Arvidsson wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/2

------------------------------------------------------------------------
On 2009-09-29T09:20:05+00:00 Wolfgang Kufner wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/3

------------------------------------------------------------------------
On 2009-09-29T09:20:59+00:00 Wolfgang Kufner wrote:

Created an attachment (id=29945)
periodic_swap_hills.png

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/4

------------------------------------------------------------------------
On 2009-09-29T09:22:37+00:00 Wolfgang Kufner wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/5

------------------------------------------------------------------------
On 2009-09-29T09:41:35+00:00 Sven Arvidsson wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/6

------------------------------------------------------------------------
On 2009-09-29T10:10:01+00:00 Wolfgang Kufner wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/7

------------------------------------------------------------------------
On 2009-09-29T12:45:18+00:00 Sven Arvidsson wrote:

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...

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/8

------------------------------------------------------------------------
On 2009-09-29T13:11:17+00:00 Wolfgang Kufner wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/9

------------------------------------------------------------------------
On 2009-09-30T11:30:00+00:00 Eric Anholt wrote:

Could you retest with this in mesa:

commit 49fbdd18ed738feaf73b7faba4d3577cd9cc3e59
Author: Eric Anholt <eric@xxxxxxxxxx>
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

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/12

------------------------------------------------------------------------
On 2009-09-30T13:15:45+00:00 Sven Arvidsson wrote:

Unfortunately no, I can still reproduce it with
49fbdd18ed738feaf73b7faba4d3577cd9cc3e59

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/14

------------------------------------------------------------------------
On 2010-03-12T17:14:40+00:00 Eric Anholt wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/15

------------------------------------------------------------------------
On 2010-05-04T21:43:21+00:00 Eric Anholt wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/17

------------------------------------------------------------------------
On 2010-05-04T22:07:05+00:00 Eric Anholt wrote:

commit ce914fff0817cb3c25a2d715f8435c6b6d6fbcdd
Author: Eric Anholt <eric@xxxxxxxxxx>
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.

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/18

------------------------------------------------------------------------
On 2010-05-05T05:54:57+00:00 Sven Arvidsson wrote:

Awesome! You rock! :)

Reply at: https://bugs.launchpad.net/mesa/+bug/438964/comments/19


** Changed in: mesa
       Status: In Progress => Fix Released

** Changed in: mesa
   Importance: Unknown => Medium

-- 
[G45] Possible memory leak with Blender use
https://bugs.launchpad.net/bugs/438964
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Mesa.