[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 <stdlib.h>
#include <stdio.h>
#include <string.h>

#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: [EMAIL PROTECTED]  (pref) | Snail: PO Box 370
       [EMAIL PROTECTED]             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to