Re: unexpected behaviour of malloc() on 7.0/amd64

Andrew MacIntyre wrote: However my reading of the updated man page suggests that the malloc options string should be "Dm" or "m" to turn off mmap() and only use sbrk() - could you clarify why "d"? Whoops, I meant "m", not "d". Jason ___ freebsd-hacke

Re: unexpected behaviour of malloc() on 7.0/amd64

Jason Evans wrote: Andrew MacIntyre wrote: 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 memo

Re: unexpected behaviour of malloc() on 7.0/amd64

Andrew MacIntyre wrote: 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 t

Re: unexpected behaviour of malloc() on 7.0/amd64

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andrew MacIntyre wrote: [snip] | 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 | KIL

unexpected behaviour of malloc() on 7.0/amd64

[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 get