From owner-freebsd-hackers Sun Sep 21 21:46:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA10985 for hackers-outgoing; Sun, 21 Sep 1997 21:46:41 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA10978 for ; Sun, 21 Sep 1997 21:46:36 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id WAA09216; Sun, 21 Sep 1997 22:46:27 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id WAA29021; Sun, 21 Sep 1997 22:46:26 -0600 (MDT) Date: Sun, 21 Sep 1997 22:46:26 -0600 (MDT) Message-Id: <199709220446.WAA29021@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sean Eric Fagan Cc: tim@ppp6431.on.sympatico.ca, hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <199709220258.TAA27605@kithrup.com> References: <199709220258.TAA27605@kithrup.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> 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. > I did not point that out because I thought it was obvious. And it doesn't > change my position: if the first malloc() succeeded, then, even if there is > no more space available after that first malloc(), the free() and subsequent > malloc() are required to work. How can they work if there is no more space after the first malloc()? There is no guarantee that once you get one byte, you're guaranteed as many as you want, be it 100 bytes or 100000 bytes. Nate