<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=GB2312" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Eric Anholt wrote: <blockquote cite="mid:1238774698.669.2.camel@gaiman.anholt.net" type="cite"> <pre wrap="">On Fri, 2009-04-03 at 09:47 +0800, Shuang He wrote: </pre> <blockquote type="cite"> <pre wrap="">Eric Anholt wrote: </pre> <blockquote 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> <pre wrap="">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 </pre> </blockquote> <pre wrap=""> Ah, if this works, that seems useful. I've just used debug mode from the bufmgr and parsed the output for bo leak tracking. </pre> </blockquote> Yep, basically I'm using it in this way to catch memory leak in X server. patch libdrm valgrind --check-leak=full X 2>&1 | tee valgrind.out do various operations kill -SIGTERM pidofX use script to analyze valgrind.out. Since we tell valgrind with gem_handle with size 0. it's easy to filter out what we need. Is it possible to make this patch for libdrm upstream? Thanks --Shuang </body> </html>