Re: Re: [farm-report] Daily Snake Farm report

> > >All these machines get the same build result; the builder gets
> > >OOM-killed. They are all "pure" 64-bit machines and they all run
> > >various versions of Linux. And while moghedien (and asmodean, which
> > >couldn't make it today) are short on RAM, the Roxen machines have
> > >one Gbyte each. It would seem something makes the tests bloat out
> > >of all proportion.

I asked the timbot, who knows about these things.  He suggested line
546 in test_b1.py:

try:
    # Verify clearing of bug #556025
    # this assumes that the max data size (sys.maxint) == max address size
    # this also assumes that the address size is at least 4 bytes
    # with 8 byte addresses, the bug is not well tested
    #
    # Note: This test is expected to SEGV under Cygwin 1.3.12 or earlier
    # due to a newlib bug.  See the following mailing list thread for the
    # details:
    #     http://sources.redhat.com/ml/newlib/2002/msg00369.html
    list(xrange(sys.maxint / 4))
except MemoryError:
    pass
else:
    raise TestFailed, 'list(xrange(sys.maxint / 4))'

This is trying to ascertain that the list allocation code does its
range checking right, and in fact, on a 32 bit system, this should
never even call malloc.

But there seems to be a bug in rangeobject.c, in range_length().  This
is a function returning int that returns r->len, which is a long.  There
*should* have been a warning for that on all 64-bit platforms, but I
can't find it on the xenofarm page.

I'll see if I can fix range_length().  Because PySequence_Size() is
defined as an int (for better or for workse), range_length() has to
return an error if the length is out of range for ints.  Then the
test will do something different (it won't test what it's supposed to
test) on 64-bit platforms; maybe we should not try this test on 64-bit
platforms, or replace sys.maxint/4 by 0x1fffffff.

I'm still hoping for better output from xenofarm.  As it is now, the
full reports mailed directly to the list were much more helpful.

--Guido van Rossum (home page: http://www.python.org/~guido/)