homepage

>>> import sys
 >>> from pickle import dumps, loads
 >>> r = xrange(sys.maxsize)
 >>> len(r) == sys.maxsize
 True
 >>> pr = loads(dumps(r))
 >>> len(pr) == len(r)
 False
 >>> pr
 xrange(0)
 >>> r
 xrange(9223372036854775807)
It breaks multiprocessing module:
http://stackoverflow.com/questions/12569977/python-large-iterations-number-fail
It fails on 2.6.6, 2.7.3. It works correctly on 3.1-3.3, pypy 1.7-1.9 x86_64 Linux.

The bug is (not surprisingly) in range_reduce in Objects/rangeobject.c, where 
 return Py_BuildValue("(O(iii))", Py_TYPE(r),
should be
 return Py_BuildValue("(O(lll))", Py_TYPE(r),
But in writing tests for this bug, I fell over another one:
>>> import sys
>>> xrange(0, sys.maxint, sys.maxint-1)
xrange(0, -4, 2147483646)

Here's the fix. There's a commented out test, which fails because of the second xrange bug (or something closely related to it).

Removing 2.6: this isn't a security issue.

Okay, the xrange stop for both its pickle and its repr is computed as:
 r->start + r->len * r->step
If this overflows, it gives a bad value. It would suffice to replace it with sys.maxint or -sys.maxint - 1 on overflow.
I'll look at this shortly.

Opened issue #16030 for the repr issue. The patch for this issue still lacks a fix for the stop value.

Updated patch, which also fixes issue 16030. It needs more tests.

Patch with tests.

Whoops; there's no need to iterate over pickle protocols in test_repr. New patch.

Updated patch: rename range_stop, as suggested in Rietveld review.

New changeset bff269ee7288 by Mark Dickinson in branch '2.7':
Issues #16029, #16030: Fix pickling and repr of large xranges.
http://hg.python.org/cpython/rev/bff269ee7288 

Now fixed. Thanks for the report!