From owner-freebsd-current Sun Apr 11 20:20: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 68BCB15270 for ; Sun, 11 Apr 1999 20:20:05 -0700 (PDT) (envelope-from green@unixhelp.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id XAA36852; Sun, 11 Apr 1999 23:17:53 -0400 (EDT) Date: Sun, 11 Apr 1999 23:17:53 -0400 (EDT) From: Brian Feldman X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: current@FreeBSD.ORG Subject: Re: swap-related problems In-Reply-To: <199904120153.SAA12154@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Apr 1999, Matthew Dillon wrote: > :I use the memory as soon as it's malloced. If it reserves a page, then > :pagefaults it into existence, the VM system knows that that page is now > :allocated. When I malloc the last available page for user use, the VM > :system knows that it's the last page. I dirty it, and there are none > :free. If I malloc(), I want to know that there is no more memory, not > :have my process killed. This is POMA. > : > :Previously, the POLA, a NULL getting returned, WORKED CORRECTLY. It did this > :for a long time. My little test program always showed this, and shows > :that now something was broken. I'll attach it to the end. > > I ran your program. malloc() appears to work properly -- returns NULL when > the datasize limit is reached. In my case, I set the datasize limit > to 64MB and ran the program. Unset the datasize limit. Now what happens? It used to return NULL, now it gets SIGKILLed. Seriously, about the killing thing, shouldn't we at least have a timer so two things don't get killed? > > ... > mallocs failed at 64956 > > Under 4.0-current. > > :> then one or two processes getting killed. Having N random processes get > :> malloc() failures can lead to serious instability with processes. > : > :Only bad code doesn't check return values of malloc(). > > You are volunteering to run through the thousands of programs & ports > to make sure that every one checks the return value for malloc()? > > Declarations that don't solve problems are not relevant. It's bad enough > that we have to kill something to handle an out-of-vm situation, we > shouldn't go off and destabilize the rest of the system while we are at it. > > -Matt > > I don't tend to use untrustworthy code for production things. I doubt there are any unchecked mallocs in something as tested as, say, X11R6.3. There could be.. Brian Feldman _ __ ___ ____ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message