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 <[email protected]> wrote: > Hi, > > On Wed, Apr 22, 2009 at 8:52 PM, Ishwor Gurung > <[email protected]>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 - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list > >
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
