From owner-freebsd-hackers Sun Sep 21 23:18:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA17732 for hackers-outgoing; Sun, 21 Sep 1997 23:18:51 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA17724 for ; Sun, 21 Sep 1997 23:18:49 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id XAA16127; Sun, 21 Sep 1997 23:17:30 -0700 (MST) From: Terry Lambert Message-Id: <199709220617.XAA16127@usr07.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: sef@Kithrup.COM (Sean Eric Fagan) Date: Mon, 22 Sep 1997 06:17:30 +0000 (GMT) Cc: tim@ppp6431.on.sympatico.ca, hackers@FreeBSD.ORG In-Reply-To: <199709220258.TAA27605@kithrup.com> from "Sean Eric Fagan" at Sep 21, 97 07:58:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text 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? The program may be context-switched between the free and the second malloc. If the implementation returns freed memory to the system, then it is possible for another process to allocate the freed memory (this assumes that the free occurs on a page boundry). When this happens, the next malloc may fail, if that was the last unallocated page in the system. Unlikely as hell, but possible, and technically in violation of the standard, at that point. > 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. Right. But because a process competes with other processes for resources, it may very well lose, right at this critical point. This is a known (and accepted) danger of memory overcommit systems. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.