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

Eric Anholt eric at anholt.net
Fri Apr 3 18:04:58 CEST 2009


On Fri, 2009-04-03 at 09:47 +0800, Shuang He wrote:
> 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

Ah, if this works, that seems useful.  I've just used debug mode from
the bufmgr and parsed the output for bo leak tracking.

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20090403/58791b2a/attachment.sig>


More information about the Intel-gfx mailing list