[dmd-internals] Memory Leak

deadal nix deadalnix at gmail.com
Sun Nov 11 11:58:46 PST 2012


Compiling the program I'm working on, dmd require more than 2Gb of memory.
Looking at the memory consumption, it doesn't look like anything is freed.

I don't use a lot of CTFE. Many templates, but most of them are not
recursive.

Compilation time and resource really is becoming an issue.


2012/11/11 Daniel Murphy <yebblies at gmail.com>

> 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
>>
>
>
> _______________________________________________
> 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/9c6c9800/attachment.html>


More information about the dmd-internals mailing list