[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: possible memory leak in make 3.81
From: |
Paul Smith |
Subject: |
Re: possible memory leak in make 3.81 |
Date: |
Mon, 15 Oct 2007 15:32:41 -0400 |
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 <address@hidden> 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