Date: Mon, 22 Sep 1997 13:27:08 +0200 From: lada@ws6303.gud.siemens.at (marino.ladavac@siemens.at) To: hackers@FreeBSD.ORG, sef@Kithrup.COM Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709221127.NAA25447@ws6423.gud.siemens.at>
next in thread | raw e-mail | index | archive | help
> From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 22 04:00:14 MET 1997
> Date: Sun, 21 Sep 1997 18:29:27 -0700 (PDT)
> From: Sean Eric Fagan <sef@Kithrup.COM>
> To: hackers@FreeBSD.ORG
> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?)
> X-Loop: FreeBSD.org
>
> In article <19970922015128.32876.kithrup.freebsd.hackers@bitbox.follo.net> you
write:
> >On Sun, Sep 21, 1997 at 04:50:38PM -0700, Jordan K. Hubbard wrote:
> >> > It doesn't. However, it has a formulation that IMHO is too
> >> > restrictive - that free() 'makes the memory available for further use
> >> > by the program' (from memory). Thus, an implementation of
> >> Bizarre, are you sure? That's exactly 180 degrees counter to what
> >> I've always learned about storage allocators: If you count on free()
> >> to not corrupt the data you pass to it, you deserve to lose and lose
> >> big.
> >My typo. I mean 'further allocation'.
>
> With either wording, eivind, fortunately, is wrong ;).
>
> malloc() is constrained to not return the same memory block twice unless it
> has been free()'d first.
>
> ANSI C also makes no distinction between OS and standard library code --
> that is, malloc() could be a system call, as far as ANSI C is concerned.
>
> The requirement there is simply that free() makes the memory available for
> further allocation (that being the only way an ANSI C conformant application
> can get at such memory).
>
> The wording for malloc() and free() was chosen very carefully, to allow
> embedded applications to work -- in such applications, there is no dynamic
> allocation of memory from the OS (since there isn't one); instead, many of
> them have a chunk of memory that is part of the program's address space, and
> malloc() and free() simply parcel it up.
>
> Lastly, the wording for free() is, as I understood it when I last read it,
> meant to convey the requirement that:
>
> char *cp = malloc(100);
> if (cp) {
> free(cp);
> cp = malloc(100);
> }
>
> always result in a non-NULL cp.
Eivind is unfortunately correct, as the above requirement need not be
fulfilled on a modern OS which is very low on swap and just cannot reserve
enough swap space for the program (because some other program reserved it
for himself between free() and malloc() again).
Thus, to achieve strict ISO C conformance on the hosted system the pages,
once allocated to the process, must not be released to the OS except on the
process rundown.
Bummer.
/Marino
>
> So, in conclusion: yes, the OS is perfectly free to have free() return the
> memory back to the OS, even though traditional systems did not do this most
> of the time. (It is a quality of implementation issue, and I think may be
> referenced as such in the X3J11 notes/comments/explanation that are not
> officially part of the standard.)
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709221127.NAA25447>