Re: possible memory leak in make 3.81
Hi there, Paul Smith wrote on 14/10/07 22:17: On Sun, 2007-10-14 at 18:33 +0100, Jon Grant wrote: Do they get free'd up when make exits? No. It's quite difficult to do this since the variables are static and so are only visible within that function. In order to free them we'd have to add them to some kind of global free list that could be walked when make was exiting. This will take time when all we want to do is exit... and anyway, the operating system will take care of cleaning that up when we exits. 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'm confident that running such cleanup code wouldn't add a performance cost. Would be neater to cleanup any heap allocations, IMHO. Makes it less cloudly when tracking other memory-leaks as well. I don't think this is a real issue; all the tools I've used for this, including things like Purify as well as free tools like Valgrind, only count memory as lost if there's nothing pointing to that memory anymore. Since this memory still has valid pointers to it, it's not a problem. Are there particular tools that you are thinking of that run into this? Devpartner's boundschecker shows up such heap allocations in its log as allocations outstanding on program exit (or some such similar description). 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. Regards, Jon ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: possible memory leak in make 3.81
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
Re: possible memory leak in make 3.81
Date: Mon, 15 Oct 2007 20:12:37 +0100 From: Jon Grant [EMAIL PROTECTED] Cc: bug-make@gnu.org Paul Smith wrote on 14/10/07 22:17: On Sun, 2007-10-14 at 18:33 +0100, Jon Grant wrote: Do they get free'd up when make exits? No. It's quite difficult to do this since the variables are static and so are only visible within that function. In order to free them we'd have to add them to some kind of global free list that could be walked when make was exiting. This will take time when all we want to do is exit... and anyway, the operating system will take care of cleaning that up when we exits. 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? No. Even DOS releases all the memory of a process that exited or was otherwise terminated. You can only lose memory on DOS if you happen to corrupt the system memory chain (by writing to bad addresses), but in that case you will have a system crash almost instantly anyway. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
It looks like this discussion may have been premature, perhaps by as little as a few weeks or so, based on the fact that Savannah has Subversion support in beta right now and that there seems to be a lot of action around GIT support on Windows that is being published either now or very shortly. So, let's table this discussion for the time being. We'll revisit it later this year when hopefully some things have shaken out. In the meantime I'm going to play with some of these other tools. If you (esp. non-Linux users) have time to try them out as well I'd really appreciate any suggestions you come up with. -- --- 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
Re: Switching from CVS to GIT
Paul Smith wrote: It looks like this discussion may have been premature, perhaps by as little as a few weeks or so, based on the fact that Savannah has Subversion support in beta right now and that there seems to be a lot of action around GIT support on Windows that is being published either now or very shortly. So, let's table this discussion for the time being. We'll revisit it later this year when hopefully some things have shaken out. In the meantime I'm going to play with some of these other tools. If you (esp. non-Linux users) have time to try them out as well I'd really appreciate any suggestions you come up with. IMO the objections to requiring MSYS/Cygwin on Windows made no sense in this discussion. Make is inherently a POSIX command line tool. Anybody using it on Windows needs a POSIX environment already anyway. Whether or not you're building Windows-native code with it doesn't really enter the equation. Aside from that, happy to leave this for later. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Switching from CVS to GIT
On Mon, 2007-10-15 at 13:36 -0700, Howard Chu wrote: IMO the objections to requiring MSYS/Cygwin on Windows made no sense in this discussion. Make is inherently a POSIX command line tool. Anybody using it on Windows needs a POSIX environment already anyway. That is definitely not true. The Windows ports of make are quite useful in native Windows environments, with no hint of POSIX (command line). They can use the Windows shell instead of the UNIX shell, etc. Certainly you're not going to be able to run any POSIX-based makefile on a Windows system without a full suite of common tools, but that doesn't mean it makes no sense in other situations. Eli can speak more directly to this, though: I've never actually used make in these situations. Cheers! -- --- 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
Re: Switching from CVS to GIT
Date: Mon, 15 Oct 2007 13:36:53 -0700 From: Howard Chu [EMAIL PROTECTED] Cc: bug-make@gnu.org, [EMAIL PROTECTED] IMO the objections to requiring MSYS/Cygwin on Windows made no sense in this discussion. Believe me, it does make sense to some. In a nutshell, if you use Cygwin or MSYS, you are forced to use them, and them alone, as there are subtle incompatibilities with other kinds of programs that can drive you up the wall sometimes. Make is inherently a POSIX command line tool. It's no more POSIX that `ls'. I hope you won't try to claim that `ls' doesn't make sense outside of a POSIX environment. Anybody using it on Windows needs a POSIX environment already anyway. Not really. Make is just a program to invoke other programs given a set of rules. It only (loosely) assumes that those programs produce files, and doesn't care much about anything else. Since not only POSIX tools can produce files, Make does not require a POSIX environment. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
