[Mono-list] Checking memory leak

Rodrigo Kumpera kumpera at gmail.com
Wed Apr 22 20:03:50 EDT 2009


Hi,

On Wed, Apr 22, 2009 at 8:52 PM, Ishwor Gurung <ishwor at loopback.ath.cx>wrote:

> Hi list,
>
> Whats an appropriate way to check for memory leak of a mono application?
>
> I googled around with some example using valgrind for mono app but
> couldn't find any concrete examples. What I've essentially done so far
> using valgrind is:
> $ valgrind --tool=memcheck --leak-check=full --show-reachable=yes mono
> ./ConnectUTest.exe
>
> This however, always produces memory leak (~14k/test on five runs so far):
>
> ==15141== LEAK SUMMARY:
> ==15141==    definitely lost: 14,408 bytes in 760 blocks.
> ==15141==    indirectly lost: 2,496 bytes in 126 blocks.
> ==15141==      possibly lost: 12,460 bytes in 419 blocks.
> ==15141==    still reachable: 2,569,056 bytes in 16,726 blocks.
> ==15141==         suppressed: 0 bytes in 0 blocks.
>
>
> Is this something I should worry about in itself or let the Mono's GC
> do its job with the memory and not worry about memory leaks? Can
> someone confirm if these are even a real memory leak (the one above
> with 14,408 bytes gone!)?
>
> Thanks.



Valgrind is the best too to dig for memory leaks. But it will only report
problems of
unmanaged memory leaks. For managed memory, just trust the GC.

Mono is supposed to do a clean shutdown, but we still have some small
non-important
fix leaks on things like support code. All of them leak a fixed set of
memory at startup.

Anyway, the best way to go is if your attach your valgrind file so I can
take a look.

Cheers,
Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20090422/35312600/attachment.html 


More information about the Mono-list mailing list