[Mono-list] Checking memory leak

[Ishwor Gurung]

Hi Andreas,

On Thu, 23 Apr 2009 05:41:09 pm Andreas Ericsson wrote:
> Ishwor Gurung 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!)?
>
> If valgrind reports it as a leak, then it is a leak, but only in the
> sense that no reference points *exactly* to the leaked area.
>
> For example, consider this code (in C, sorry. I don't know how to
> produce a leak in C#):
>
> --%<--%<--
> static unsigned long offset;
> static char *buf;
>
> void some_func(void)
> {
> 	buf = malloc(5000);
> 	offset = 4500;
> 	buf += offset;
> }
> --%<--%<--
>
> but that's not entirely true, because the exact reference to *buf
> can be determined by
>
> 	exact_ref = buf - offset;

Yep.

> Granted, this is a pretty weird way of using offsets, but it's a
> valid one that can be done without leaking memory. I've sometimes
> used it myself to microoptimize tight loops, but only on static
> sized data where the offset is always
>
> 	exact_ref = buf - STATIC_SIZE;

Yep

> In short; Valgrind sometimes gives false positives. So long as
> the leaked memory is small-ish (14K is nothing) and doesn't
> grow over time, I wouldn't worry about it.

Yep I haven't done hardcore regression on it yet but yeah I'd assume ~14k is 
OK for now. Let me code few more functions and see in the future. Thanks.

-- 
	Cheers,
	Ishwor Gurung
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ximian.com/pipermail/mono-list/attachments/20090426/26bbbf13/attachment.bin