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
possible memory leak in make 3.81
Hi, In function library_search(), libpatterns and buf is malloced memory in line 1486 and 1553 respectively. They are not freed. Is this true? - Zhongxing Xu ___ 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 Sun, 2007-10-14 at 20:40 +0800, Zhongxing Xu wrote: In function library_search(), libpatterns and buf is malloced memory in line 1486 and 1553 respectively. They are not freed. Is this true? Correct, they are not freed--but no, this is not a memory leak. These variables are declared static so the next time the function is invoked they still point to that same memory buffer. This is just a way to avoid allocating/freeing a local memory buffer over and over. -- --- 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
Paul Smith wrote on 14/10/07 17:39: On Sun, 2007-10-14 at 20:40 +0800, Zhongxing Xu wrote: In function library_search(), libpatterns and buf is malloced memory in line 1486 and 1553 respectively. They are not freed. Is this true? Correct, they are not freed--but no, this is not a memory leak. These variables are declared static so the next time the function is invoked they still point to that same memory buffer. This is just a way to avoid allocating/freeing a local memory buffer over and over. Do they get free'd up when make exits? Would be neater to cleanup any heap allocations, IMHO. Makes it less cloudly when tracking other memory-leaks as well. Cheers, Jon -- linkme: http://www.linkedin.com/in/jongrant weblog: http://jguk.org/ ___ 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 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. 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? -- --- 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
