From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 16:20:02 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A32161065676 for ; Wed, 17 Sep 2008 16:20:02 +0000 (UTC) (envelope-from andymac@bullseye.apana.org.au) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id 261828FC15 for ; Wed, 17 Sep 2008 16:20:01 +0000 (UTC) (envelope-from andymac@bullseye.apana.org.au) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFANbG0Eg7pzeZ/2dsb2JhbACBY7c+gWc X-IronPort-AV: E=Sophos;i="4.32,416,1217773800"; d="scan'208";a="208543545" Received: from ppp59-167-55-153.lns1.cbr1.internode.on.net (HELO bullseye.apana.org.au) ([59.167.55.153]) by ipmail05.adl2.internode.on.net with ESMTP; 18 Sep 2008 01:34:42 +0930 Received: from [192.168.63.10] (tenring.andymac.org [192.168.63.10]) by bullseye.apana.org.au (8.14.2/8.14.2) with ESMTP id m8HFtCIv088870 for ; Thu, 18 Sep 2008 01:55:12 +1000 (EST) (envelope-from andymac@bullseye.andymac.org) Message-ID: <48D12AD4.1000806@bullseye.andymac.org> Date: Thu, 18 Sep 2008 02:05:40 +1000 From: Andrew MacIntyre User-Agent: Thunderbird 2.0.0.14 (OS/2/20080509) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: unexpected behaviour of malloc() on 7.0/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 16:20:02 -0000 [If this is not an appropriate forum for this query, please suggest a more appropriate one] In investigating a Python 2.6rc1 regression test failure on FreeBSD 7.0/amd64, as far as I can tell, malloc() does not return NULL when available memory (including swap) is exhausted - the process just gets KILLed. Using ulimit -v to set a virtual memory use limit below the available memory does result in malloc() returning NULL when the limit is hit. The Python regression test concerned does not fail on FreeBSD 7.0/i386, however the C program below exhibits the unexpected behaviour on both 7.0/amd64 and 7.0/i386. The C program below does behave as expected on FreeBSD 6.3/i386; I cannot currently test its behaviour on FreeBSD 6.3/amd64. I can't see this behaviour documented in the malloc() man page. I attempted to search the gnats database but the only mention of "malloc" is not related to this issue and doesn't involve this architecture. Is this the intended behaviour? ---8<---8<---8<--- #include #include #include #define CHUNK_SIZE 1024*1024 int main(void) { char* t; char buffer[256]; int i = 0; while (1) { if ((t = malloc(CHUNK_SIZE)) == NULL) { sprintf(buffer, "chunks allocated: %d\n", i); printf(buffer); break; } memset(t, 0, CHUNK_SIZE); ++i; } return 0; } ---8<---8<---8<--- Thanks, Andrew. -- ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia