<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Eric Anholt wrote: <blockquote cite="mid:1238696268.7426.3.camel@gaiman.anholt.net" type="cite"> <pre wrap="">On Thu, 2009-04-02 at 15:13 +0800, Shuang He wrote: </pre> <blockquote type="cite"> <pre wrap="">Alexander E. Patrakov wrote: </pre> <blockquote type="cite"> <pre wrap="">Shuang He <a class="moz-txt-link-rfc2396E" href="mailto:shuang.he@intel.com"><shuang.he@intel.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">The patch of libdrm for testing is attached. You'll need valgrind-devel installed to compile it. </pre> </blockquote> <pre wrap="">It may be a good idea to put this under an ifdef, and make the ./configure script accept the --with-valgrind switch. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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). </pre> </blockquote> 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 <blockquote cite="mid:1238696268.7426.3.camel@gaiman.anholt.net" type="cite"> <pre wrap="">Other than that, the configure.ac detection was what I was going to ask for, and that looks fine now. </pre> <blockquote type="cite"> <pre wrap="">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 <a class="moz-txt-link-abbreviated" href="mailto:Intel-gfx@lists.freedesktop.org">Intel-gfx@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/intel-gfx">http://lists.freedesktop.org/mailman/listinfo/intel-gfx</a> </pre> </blockquote> </blockquote> </body> </html>