[Mono-list] Checking memory leak

[Mike Christensen]

I guess this really depends on what you mean by a memory leak..  If you mean
the object is not reachable and on the queue to be garbage collected, one
might "just trust the GC".  However, there's also a lot of value on being
able to see what objects are on the heap (and large object heap), what
generation they're in, etc.  There may be objects that you believe are no
longer used, but the runtime still sees them as reachable due to your own
coding errors, and not GC bugs.

The .NET world has all sorts of great tools like SOS/Windbg as well as all
sorts of third party analysis.  Is there anything in the Mono world to help
out with this?

Mike

On Wed, Apr 22, 2009 at 5:03 PM, Rodrigo Kumpera <kumpera at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20090423/976bd756/attachment.html