Date: Mon, 22 Sep 1997 00:40:18 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: nate@mt.sri.com (Nate Williams) Cc: sef@kithrup.com, tim@ppp6431.on.sympatico.ca, hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709220540.AAA00431@dyson.iquest.net> In-Reply-To: <199709220446.WAA29021@rocky.mt.sri.com> from Nate Williams at "Sep 21, 97 10:46:26 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709220540.AAA00431>