On Mon, 2007-10-15 at 20:12 +0100, Jon Grant wrote: > the OS should cover that, but in some case I wonder if there may be a > leak left. Would the DOS version for instance result in lost memory the > OS cannot reallocate? (I'm not a DOS expert to answer that)
I would be surprised, since DOS is so simple, if it doesn't clean up everything. But, Eli perhaps could tell us more. > I'm confident that running such cleanup code wouldn't add a performance > cost. Well, of course there would be SOME performance cost. I do agree it would almost certainly not be detectable in this particular case. However, there are a LOT of places in make where no attempt is made to clean up memory: we never try to walk the various variable, target, and prerequisite lists and free all that; we never try to free up the directory caching information; etc. I think doing all that would be a major effort to little purpose... and I'm not so sure that _that_ performance change would not be detectable, particularly for large environments. I've seen builds where make uses 1G or so of memory at its peak... and make uses a lot of smaller allocations which means a lot of calls to free() and a lot of walking of data structures. And, if you're not going to free everything, why bother freeing something as minor as these static buffers? > Devpartner's boundschecker shows up such heap allocations in its log as > "allocations outstanding on program exit" (or some such similar > description). Hrm. Can it tell the difference between outstanding allocations that are "lost" and those which aren't? If so then I'd suggest just ignoring the "not lost" outstanding allocations :-). > BTW, I wonder if you run all the different tests in the testsuite > through valgrind? An automated way of doing that would be really handy I > think.. I did that for a client recently. Absolutely. Just add the -valgrind argument (you have to run it directly, not via "make check"): make cd tests ./run_make_tests -make ../make -valgrind I'm not sure if the result is EXACTLY what you want but I did put a bit of effort, anyway, into making it helpful. It will remove any output file that contains no reports, IIRC. Unfortunately there are a few memory leaks in the system which are annoyingly intractable. However, the new string cache has eliminated a lot of those in the current CVS head. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make