>>> 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!