Martin v. Löwis wrote:
I haven't yet tried posting a query to a FreeBSD list, as it could simply
be a bug on amd64, but I was wondering whether there was anything (other
than deactivating tests and documenting use of ulimit -v on this
platform) that could be done to work around this behaviour.
I think it should be possible to debug this (for people with access to
such a system, and appropriate skills).
I find it hard to believe that a large malloc will simply crash the
process, rather than returning NULL. More likely, there is a NULL
returned somewhere, and Python (or libc) fails to check for it.
A simple C program doing a repetitive malloc(), much as pymalloc would
with continuous demand, does indeed not see any NULL from malloc() when
swap is exhausted but the process gets KILLed (the allocated memory does
have to be written to to force the situation...)
I'll take this up with FreeBSD folk, but I'm open to ideas as to how
best to deal with the problem in the context of the test suite pending
resolution by FreeBSD.
Regards,
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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
