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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
