Created attachment 29808 [details]
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.
-- 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: 184.108.40.2061
-- mesa: de25f82067bca5231fb968190f6c12cb517d62ff
-- drm: 67e4172394a88d4922fb8d9c7c3d96ce7e02c5a6
-- kernel: 2.6.31
Created attachment 29809 [details]
meminfo before blender use
Created attachment 29810 [details]
meminfo after blender use
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".)
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.
Created attachment 29945 [details]
Created attachment 29946 [details]
vmstat output including the time of the periodic_swap_hills.png screenshot
That's an interesting observation. My system does not have any swap, which I should have mentioned before.
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.
This is also reproducible with linux 2.6.32-rc1.
Output of cat /sys/kernel/debug/dri/0/gem_objects when this happens:
-566599680 object bytes
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...
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.
Could you retest with this in mesa:
Author: Eric Anholt <email@example.com>
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.
Unfortunately no, I can still reproduce it with 49fbdd18ed738feaf73b7faba4d3577cd9cc3e59
*** Bug 26461 has been marked as a duplicate of this bug. ***
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.
Author: Eric Anholt <firstname.lastname@example.org>
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.
Awesome! You rock! :)
on Jul 02, 2016 at 07:24:20.
(provided by the Example extension).