bug-make
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]