Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Apr 1999 23:17:53 -0400 (EDT)
From:      Brian Feldman <green@unixhelp.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        current@FreeBSD.ORG
Subject:   Re: swap-related problems
Message-ID:  <Pine.BSF.4.05.9904112315230.36814-100000@janus.syracuse.net>
In-Reply-To: <199904120153.SAA12154@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9904112315230.36814-100000>