[dmd-internals] Memory Leak

Alex Rønne Petersen xtzgzorex at gmail.com
Sat Nov 10 23:28:57 PST 2012


On Sun, Nov 11, 2012 at 8:26 AM, 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 as a whole is written for garbage collection. It just so happens
that it doesn't use one at the moment, which means a lot of things
will leak.

Regards,
Alex


More information about the dmd-internals mailing list