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

[Shuang He]

Eric Anholt wrote:
> 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.
>
>   
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



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