Date: Mon, 22 Sep 1997 06:17:30 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: sef@Kithrup.COM (Sean Eric Fagan) Cc: tim@ppp6431.on.sympatico.ca, hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709220617.XAA16127@usr07.primenet.com> In-Reply-To: <199709220258.TAA27605@kithrup.com> from "Sean Eric Fagan" at Sep 21, 97 07:58:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709220617.XAA16127>