Charles-François Natali added the comment:

Alright, it bothered me so I wrote a small C testcase (attached),
which calls malloc in a loop, and can call memset upon the allocated
block right after allocation:

$ gcc -o /tmp/test /tmp/test.c; /tmp/test
malloc() returned NULL after 3050MB
$ gcc -DDO_MEMSET -o /tmp/test /tmp/test.c; /tmp/test
malloc() returned NULL after 2130MB

Without memset, the kernel happily allocates until we reach the 3GB
user address space limit.
With memset, it bails out way before.

I don't know what this'll give on 64-bit, but I assume one should get
comparable result.

I would guess that the reason why the Python list allocation fails is
because of the exponential allocation scheme: since memory is
allocated in large chunks before being used, the kernel happily
overallocates.
With a more progressive allocation+usage, it should return ENOMEM at some point.

Anyway, that's probably off-topic!

----------
Added file: http://bugs.python.org/file35059/test.c

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21233>
_______________________________________
#include <stdio.h>
#include <stdlib.h>
#include <string.h>


#define BLOCK_SIZE (10*1024*1024)


int main(int argc, char *argv[])
{
    unsigned long size = 0;
    char *p;

    while ((p = malloc(BLOCK_SIZE)) != NULL) {
#ifdef DO_MEMSET
        memset(p, 0, BLOCK_SIZE);
#endif
        size += BLOCK_SIZE;
    }

    printf("malloc() returned NULL after %uMB\n", (size/(1024*1024)));

    exit(EXIT_SUCCESS);
}
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to