From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 06:41:05 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9F6E37B401 for ; Thu, 24 Jul 2003 06:41:05 -0700 (PDT) Received: from vnode.vmunix.com (vnode.vmunix.com [64.7.135.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BD9643FA3 for ; Thu, 24 Jul 2003 06:41:05 -0700 (PDT) (envelope-from gabor@vmunix.com) Received: by vnode.vmunix.com (Postfix, from userid 1004) id 9CD98A1AD8; Thu, 24 Jul 2003 13:41:04 +0000 (GMT) Date: Thu, 24 Jul 2003 09:41:04 -0400 From: Gabor To: Doug White Message-ID: <20030724134104.GA83799@vmunix.com> References: <20030723173427.GA72876@vmunix.com> <20030723140329.C92624@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723140329.C92624@carver.gumbysoft.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.7-STABLE cc: freebsd-stable@freebsd.org Subject: Re: malloc does not return null when out of memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2003 13:41:06 -0000 On Wed, Jul 23, 2003 at 02:09:00PM -0700, Doug White wrote: # On Wed, 23 Jul 2003, Gabor wrote: # # > We have a little soekris box running freebsd that uses racoon for key # > management. It's used for setting up an ipsec tunnel. I noticed that # > one of these devices lost the tunnel this morning. I looked in the # > log and saw this # > # > Jul 23 01:37:57 m0n0wall /kernel: pid 80 (racoon), uid 0, was killed: out of swap space # # [...] # # > Here is the tail end of the output. It dies when trying to poke at # > the memory using memset. If I just malloc without the memset, it # > never even dies. # # That's normal. If you malloc() memory and never touch it then it is never # actually allocated. It's not normal. If malloc cannot allocate memory it should return a null pointer. How would my application know there is no more memory? Dying is not a very good behavior. The C standard and even the man page says that malloc will return null when there is no more memory to be had by the process. It shouldn't return a bogus pointer so I can happily attempt to use it and then my program bombs. Obviously sbrk is somehow broken and allows a break to be set when it shouldn't. # Your problem is that you're running out of memory. Try killing off # unneeded daemons and set maxusers to a low value (like 32). Also try # reducing the size of your mfs partitions, if you're using rc.diskless2. I # don't think raccoon is much of a memory pig, unless you have a huge number # of connections. # # > The kernel for this has the NO_SWAPPING option enabled since there is # > essentially no disk, it boots from a CF. # # Do you have the 32MB or 64MB version? I have a net4501 (64MB) and I still # have 39MB free. Its just running natd, sshd, named and dhcpd. I believe it's 64M and we're using mpd and racoon on it to set up an ipsec tunnel. There is usually about 21M of free memory on it. We have 14 live boxes in the field and only one has experienced this problem but the problem is reproducable on all of them using the little C program.