Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!spool.mu.edu!darwin.sura.net!haven.umd.edu!uunet!mcsun!sun4nl!eur.nl!pk From: pk@cs.few.eur.nl (Paul Kranenburg) Subject: Re: Marvellous Memory Munching Make Message-ID: <1992Sep28.101928.8607@cs.few.eur.nl> Keywords: where does it go? what does it do? Sender: news@cs.few.eur.nl Reply-To: pk@cs.few.eur.nl Organization: Erasmus University Rotterdam References: <1992Sep25.020038.28923@citec.oz.au> <1992Sep25.174613.19954@fcom.cc.utah.edu> Date: Mon, 28 Sep 1992 10:19:28 GMT Lines: 21 In <1992Sep25.174613.19954@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >In article <1992Sep25.020038.28923@citec.oz.au> sgccseh@citec.oz.au (Steve Hocking) writes: >> >> I've noticed that make seems to eat memory like there's no tomorrow. >>Often I have to stop & restart a make because gcc et al complains about >>being out of memory. I know that if I reinstall with something other than >>the default swap size, then the problem will be hidden, but it seems like >>this is not the optimal solution. BTW the leak only seems to happen when >>make actually kicks off another program. >This is because of the malloc before the exec. Change the "vfork" used to >start the child process to a "fork" and the memory leak will go away. This >will make make somewhat slower, but since the malloc occures into the parents >heap, this is the culprit. The problem gets worse on larger environments >set up by the user. In the new VM system, the only difference between fork() and vfork() is in scheduling: the parent waits until its child either exits or execs. Sharing of address spaces on longer occurs.