[Intel-gfx] Enhance our tests with graphics memory issue detection

Shuang He shuang.he at intel.com
Fri Apr 3 03:47:40 CEST 2009


Eric Anholt wrote:
> On Thu, 2009-04-02 at 15:13 +0800, Shuang He wrote:
>   
>> Alexander E. Patrakov wrote: 
>>     
>>> Shuang He <shuang.he at intel.com> wrote:
>>>   
>>>       
>>>> The patch of libdrm for testing is attached. You'll need
>>>> valgrind-devel installed to compile it.
>>>>     
>>>>         
>>> It may be a good idea to put this under an ifdef, and make
>>> the ./configure script accept the --with-valgrind switch.
>>>
>>>   
>>>       
>> Yeah, good idea. I have attached the updated patch for libdrm. It will
>> make ./configure script accept --enable-valgrind switch. 
>> It's disabled by default. 
>>     
>
> What does the VALGRIND_MALLOCLIKE_BLOCK on the gem_handle achieve?  It's
> not a malloc-like block (no virtual address space, just a kernel
> refcounted object handle).
>   
It's meant to catch memory leak. Considering following sequence of 
operation:
    bo_alloc
    map BO
    unmap BO
    then without bo_unreference
BO won't actually be freed, since (bo->refcount == 0) will never be 
true. We can't catch this scenario, if we only track BO memory map.  And 
this is happening for bug #20704, and some VT-switch memory leak that 
Lukas fixed.
As for bug #20704, we can catch memory leak like this:
==26083== 0 bytes in 160 blocks are definitely lost in loss record 2 of 112
==26083==    at 0x554D831: drm_intel_gem_bo_alloc_internal 
(intel_bufmgr_gem.c:428)
==26083==    by 0x55491F3: drm_intel_bo_alloc_for_render (intel_bufmgr.c:58)
==26083==    by 0x55B1476: i830_uxa_create_pixmap (i830_exa.c:961)
==26083==    by 0x55C5D5A: I830DRI2CreateBuffers (i830_dri.c:1588)
==26083==    by 0x4026D5C: DRI2GetBuffers (dri2.c:146)
==26083==    by 0x5527294: dri2GetBuffers (glxdri2.c:363)
==26083==    by 0x565DE0F: ???
==26083==    by 0x565E260: ???
==26083==    by 0x56392BD: ???
==26083==    by 0x55270BB: __glXDRIcontextMakeCurrent (glxdri2.c:168)
==26083==    by 0x551A1D8: DoMakeCurrent (glxcmds.c:635)
==26083==    by 0x551C875: __glXDispatch (glxext.c:523)

Thanks
    --Shuang
> Other than that, the configure.ac detection was what I was going to ask
> for, and that looks fine now.
>
>   
>> plain text document attachment (drm.valgrind.patch)
>> diff --git a/configure.ac b/configure.ac
>> index 8be1e2a..d7544fe 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -47,6 +47,10 @@ AC_ARG_ENABLE(nouveau-experimental-api,
>>  	      [Enable support for nouveau's experimental API (default: disabled)]),
>>  	      [NOUVEAU=$enableval], [NOUVEAU=no])
>>  
>> +AC_ARG_ENABLE(valgrind,     AS_HELP_STRING([--enable-valgrind],
>> +                                [Build with valgrind support (default: disabled)]),
>> +                                [VALGRIND=$enableval], [VALGRIND=no])
>> +
>>  dnl ===========================================================================
>>  dnl check compiler flags
>>  AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
>> @@ -131,6 +135,10 @@ if test "x$HAVE_CAIRO" = xyes; then
>>  fi
>>  AM_CONDITIONAL(HAVE_CAIRO, [test "x$HAVE_CAIRO" = xyes])
>>  
>> +if test "x$VALGRIND" = xyes; then
>> +        AC_DEFINE(VALGRIND, 1, [Have valgrind support])
>> +fi
>> +
>>  
>>  AC_SUBST(WARN_CFLAGS)
>>  AC_OUTPUT([
>> diff --git a/libdrm/intel/intel_bufmgr_gem.c b/libdrm/intel/intel_bufmgr_gem.c
>> index e48778c..6f1ffb8 100644
>> --- a/libdrm/intel/intel_bufmgr_gem.c
>> +++ b/libdrm/intel/intel_bufmgr_gem.c
>> @@ -38,6 +38,9 @@
>>  #include "config.h"
>>  #endif
>>  
>> +#ifdef VALGRIND
>> +#include <valgrind/valgrind.h>
>> +#endif
>>  #include <xf86drm.h>
>>  #include <fcntl.h>
>>  #include <stdio.h>
>> @@ -424,6 +427,10 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr, const char *name,
>>      DBG("bo_create: buf %d (%s) %ldb\n",
>>  	bo_gem->gem_handle, bo_gem->name, size);
>>  
>> +#ifdef VALGRIND
>> +    VALGRIND_MALLOCLIKE_BLOCK( bo_gem->gem_handle, 0, 0, 0 );
>> +#endif
>> +
>>      return &bo_gem->bo;
>>  }
>>  
>> @@ -553,6 +560,10 @@ drm_intel_gem_bo_unreference_locked(drm_intel_bo *bo)
>>  	struct drm_intel_gem_bo_bucket *bucket;
>>  	uint32_t tiling_mode;
>>  
>> +#ifdef VALGRIND
>> +        VALGRIND_FREELIKE_BLOCK( bo_gem->gem_handle, 0 );
>> +#endif
>> +
>>  	if (bo_gem->relocs != NULL) {
>>  	    int i;
>>  
>> @@ -635,6 +646,10 @@ drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable)
>>      }
>>      DBG("bo_map: %d (%s) -> %p\n", bo_gem->gem_handle, bo_gem->name,
>>  	bo_gem->mem_virtual);
>> +
>> +#ifdef VALGRIND
>> +    VALGRIND_MALLOCLIKE_BLOCK( bo_gem->mem_virtual, bo->size, 0, /*is_zeroed*/0 );
>> +#endif
>>      bo->virtual = bo_gem->mem_virtual;
>>  
>>      if (bo_gem->global_name != 0 || !bo_gem->swrast) {
>> @@ -749,6 +764,10 @@ drm_intel_gem_bo_unmap_gtt(drm_intel_bo *bo)
>>      bo->virtual = NULL;
>>      pthread_mutex_unlock(&bufmgr_gem->lock);
>>  
>> +#ifdef VALGRIND
>> +    VALGRIND_FREELIKE_BLOCK( bo_gem->mem_virtual, bo->size );
>> +#endif
>> +
>>      return ret;
>>  }
>>  
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>     

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20090403/43fc0ff6/attachment.html>


More information about the Intel-gfx mailing list