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
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
IMO, there shouldn't be any tests in the test suite that rely on
exhaustion of all available
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
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.
On Sep 17, 2008, at 10:53 AM, Andrew MacIntyre wrote:
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
Unbelievable as this may seem, this crazy over-committing malloc
behavior is by now a classic -- I first fought against it in 1990,
when IBM released AIX 3 for its then-new RS/6000 line of workstations;
in a later minor release they did provide a way to optionally switch
this off, but, like on
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.
Not sure what the test purpose is: if it is to test that you get a
MemoryError in cases where you ask for more than Python could
On Wed, Sep 17, 2008 at 08:21:55AM -0700, Alex Martelli wrote:
Unbelievable as this may seem, this crazy over-committing malloc
behavior is by now a classic -- I first fought against it in 1990,
when IBM released AIX 3 for its then-new RS/6000 line of workstations;
in a later minor release
On Sep 17, 2008, at 12:45 PM, Martin v. Löwis 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.
Not sure what the test purpose is: if it is to test that you get a
There is an option at least on linux to hack using ld preload to use
another memory manager that respond the way needed... at least that was
what I was told today at lunch. (if ulimit is not enough for any reason).
For Python, there would be much less hackish ways. Most if not all calls
to
10 matches
Mail list logo
