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: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4