From owner-freebsd-hackers Mon Sep 22 01:03:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA23953 for hackers-outgoing; Mon, 22 Sep 1997 01:03:08 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA23945 for ; Mon, 22 Sep 1997 01:03:03 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id DAA00175; Mon, 22 Sep 1997 03:02:40 -0500 (EST) From: "John S. Dyson" Message-Id: <199709220802.DAA00175@dyson.iquest.net> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-Reply-To: <199709220627.XAA16498@usr07.primenet.com> from Terry Lambert at "Sep 22, 97 06:27:34 am" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 22 Sep 1997 03:02:40 -0500 (EST) Cc: karpen@ocean.campus.luth.se, sef@Kithrup.COM, hackers@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert said: > > > Then it would indeed be guaranteed that the second malloc() would succeed. > > > > Am I right? Maybe I'm completely off instead? :-) > > You're wrong. Memory is overcommited. This means that there is no > guarantee that a backing page exists for the kernel to be able to > associate it with the process as a result of the fault. > > I would tend to use softer language, but there is no guarantee that memory exists immediately after a 400K malloc, for example. Those pages aren't faulted until needed. There is some attempt to avoid the most obvious problems, but no guarantees. -- John dyson@freebsd.org jdyson@nc.com