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