Andrew MacIntyre wrote:
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.
The response I got from Jason Evans (author of the new malloc() implementation), along with that of another respondent, indicates that the behaviour on FreeBSD 7.1 and later will (mostly) be restored to that similar to 6.x and earlier through the default use of sbrk() and consequent obedience to the data segment size limit (ulimit -d) - which defaults to 512MB in a standard FreeBSD install in recent times. The residual problem (as of 7.1) is that malloc() defaults to falling back to the mmap() strategy when it can't get more address space via sbrk(). As noted in the tracker item for issue 3862, the only way to control this is the virtual memory size limit (ulimit -v), which unfortunately defaults to "unlimited"... FreeBSD's malloc() can be tuned in several ways, so it is possible to force use of the sbrk() only strategy (as of 7.1) which would exactly match behaviour of the old malloc(). It seems to me that the most practical way forward is to just institute a policy that tests that want to try and test out of memory behaviour must ensure that appropriate resource limits are in place; if they can't (such as because the platform running the tests doesn't support getrlimit()/setrlimit()) the test should be skipped. As Mark Dickinson has suggested a patch for issue 3862 which should worm around the issue with test_array on 64 bit platforms, I think we can move forward for the time being. Cheers, 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