[dmd-internals] Memory Leak

[David Held]

I see.  And does anyone report running out of memory due to this?  It 
seems like it would mostly be a problem with CTFE, but could be a 
problem on any large project, I suppose.

Dave


On 11/10/2012 11:34 PM, Daniel Murphy wrote:
> This isn't a bug, dmd does not free memory (with some exceptions), it 
> assumes a garbage collector is present.
>
> On Sun, Nov 11, 2012 at 6:26 PM, David Held <dmd at wyntrmute.com 
> <mailto:dmd at wyntrmute.com>> wrote:
>
>     While writing some unit tests for Dsymbol, I noticed that
>     Dsymbol::toPrettyChars() leaks almost everywhere.  In the simple
>     case where a symbol has no parent, it just returns toChars(),
>     which does not leak (at least I don't think it does).  However,
>     whenever the symbol has a parent (or many), the returned string is
>     composed, which requires that it is allocated dynamically (via
>     mem.malloc()). Even though the caller owns the string, and even
>     though it is called dozens of times, it appears that none of the
>     callers are properly disposing of the result.  Unfortunately, it
>     is a bit messy to do so, because you must free the string *only*
>     if it has a parent, which is a pretty bad implementation leak,
>     IMO.  Here is a place where std::string would have worked nicely. ;)
>
>     I suspect this has gone unnoticed because A) dmd probably has a
>     relatively small memory footprint to begin with or B) most
>     invokations of toPrettyChars() are during a call to error(), so
>     the compiler is about to quit anyway.  What to do?  Leave it
>     alone?  Try to fix it?  Note that fixing it without changing
>     toPrettyChars() would require adding 2-3 lines of code to almost
>     every call.
>
>     Dave
>
>
>     P.S.  Incidentally, this bug is one that is not easily caught with
>     assertions (where would you place the assert that the string was
>     freed?).  Fortunately, it is caught by unit testing; but it could
>     also have been caught by documenting that the caller owns the
>     string.  This is why you really want all 3 approaches to code quality.
>
>     _______________________________________________
>     dmd-internals mailing list
>     dmd-internals at puremagic.com <mailto:dmd-internals at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20121111/cf32d8a7/attachment-0001.html>