From owner-freebsd-hackers Sun Sep 21 22:41:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA14830 for hackers-outgoing; Sun, 21 Sep 1997 22:41:53 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA14815 for ; Sun, 21 Sep 1997 22:41:48 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id AAA00431; Mon, 22 Sep 1997 00:40:18 -0500 (EST) From: "John S. Dyson" Message-Id: <199709220540.AAA00431@dyson.iquest.net> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <199709220446.WAA29021@rocky.mt.sri.com> from Nate Williams at "Sep 21, 97 10:46:26 pm" To: nate@mt.sri.com (Nate Williams) Date: Mon, 22 Sep 1997 00:40:18 -0500 (EST) Cc: sef@kithrup.com, tim@ppp6431.on.sympatico.ca, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams said: > > >> char *cp = malloc(100); > > >> if (cp) { > > >> free(cp); > > >> cp = malloc(100); > > >> } > > >No, if you want the above code to always result in a non-NULL cp, > > >free() cannot ever return the memory back to the OS. > > > > Really? Would you like to explain that idiotic statement? Back it up with > > some facts, explanations, or justifications? > > If between the lines of free(cp) you get a context switch, another > application allocates enough memory to completely use up the VM in the > system, and then the process is switched to again, the second malloc > could fail due to lack of VM. Again, this is a *very* rare case, but > could happen if free() returns memory to the OS. > Actually, the problem can occur after a successful malloc, with the type of swap allocation that we have. Since we don't reserve swap space, there can be a program failure at fault time due to VM limits. I think that this whole discussion handles only an end-case, that if it continues on, will have a possibility of us making a decision towards some mediocre compromise. IMO, allowing malloc to return memory to the system, either by address space modification, or through hints to the OS, shouldn't cause any reasonable portability problems. It is only in the case of the system being in "sorry shape" that there is any difference in behavior between malloc proactively freeing memory or not. Just my 2p or 2 cents or whatever. -- John dyson@freebsd.org jdyson@nc.com