[dmd-internals] Memory Leak

[Daniel Murphy]

Yes, it's very easy to make it run out of memory with ctfe or recursive
templates.

The garbage collector works as far as I know, but needs some performance
tuning.

On Sun, Nov 11, 2012 at 7:06 PM, David Held <dmd at wyntrmute.com> wrote:

>  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> 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
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>
>
>
> _______________________________________________
> dmd-internals mailing listdmd-internals at puremagic.comhttp://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/f4e2bb30/attachment.html>