[Mesa-dev] leak of gem_objects on intel i965

[Lampersperger Andreas]

Hello,

I've tried 2.6.39.1 and the gem_objects leak still exists.

I found the leak also on a i915 not only on a i965.

It only disappears if I set LIBGL_ALLWAYS_SOFTWARE (not really an opinion ;-).

Now I can try to update user space libraries, what lib would you suspect most?

libdrm 2.4.23
xorg-server 1.10.2
xf86-video-intel-2.15
gtkglext-1.2.0
mesa-7.10.2

Or I can continue debugging, if anyone can give me a hint to the following question:

In which function are the buffers freed, which are received 
from xserver via DRI2GetBuffersWithFormat(..) at dri2.c:431?

-Andreas


-----Ursprüngliche Nachricht-----
Von: Chris Wilson [mailto:chris at chris-wilson.co.uk] 
Gesendet: Dienstag, 14. Juni 2011 16:31
An: Lampersperger Andreas; mesa-dev at lists.freedesktop.org
Betreff: Re: AW: AW: [Mesa-dev] leak of gem_objects on intel i965

On Tue, 14 Jun 2011 15:21:13 +0200, Lampersperger Andreas <lampersperger.andreas at heidenhain.de> wrote:
> Which Versions of 
> 
> libdrm 
> mesa 
> xf86_video_intel
> xorg-server
> gtkglext
> linux-kernel
> 
> do you use?

All apart from gtkglext were compiled from git with my own patches
included. None of those patches were to address this issue.
 
> You think the most suspect part is i915.ko? I watched (via systemtap) all calls to drm_gem_object_alloc(), drm_gem_object_free(), and to drm_gem_object_destroy() (in drm.ko) and I saw that with every realize/unrealize of simple.c there are 2 drm_gem_object_alloc() calls (between other drm_gem_object_allocs/frees) where I cannot found a suitable drm_gem_object_free or .._destroy call. This leads me to suspect the user-space. Or is this wrong, that for every drm_gem_object_alloc()-call there have to be a drm_gem_object_free()-call?

Also beware that userspace caches inactive objects. They should be
released after a second or so, but that behaviour will obfuscate what is
happening lower down.

> Can you give me some hint, where to start debugging/watching in i915.ko? 

Yes, start from 2.6.39. But on second thoughts, the v2.6.33
drm_gem_vm_close() has the unref but not the close, which is a different
type of leak.

If the leak still occurs with 2.6.39, it is definitely in userspace. ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

-------------- next part --------------
-------------------------------------------------------------------------------------------------------
Registergericht: Traunstein / Registry Court: HRB 275 ? Sitz / Head Office: Traunreut
Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard
Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman),
Michael Grimm, Matthias Fauser, Sebastian Tondorf

E-Mail Haftungsausschluss / E-Mail Disclaimer: http://www.heidenhain.de/disclaimer