Issue2323

This code recurses infinitely on Jython2.7RC2:

>>> class X(object):
...     def __reduce__(self): return object.__reduce__(self)
...
>>> X().__reduce__()
Traceback (most recent call last):
 ...
RuntimeError: maximum recursion depth exceeded (Java StackOverflowError)

But works fine on CPython 2.7 and PyPy 2.5:

>>> class X(object):
...    def __reduce__(self): return object.__reduce__(self)
...
>>> X().__reduce__()
(<function _reconstructor at 0x1028912a8>, (<class '__main__.X'>, <type 'object'>, None))

Interestingly, using `super(X,self).__reduce__()` works correctly.

I suspect this may be a known issue because the tests for it were disabled in https://hg.python.org/jython/rev/c82067c0766f.

Those tests were disabled per this megabug, http://bugs.jython.org/issue1861, just to get Jython running, but then not re-addressed.

Any packages this is specifically impacting, so we can determine prioritization?

I suspect this is an unstopped super call, but will investigate when we have a chance.

I encountered this while making the `zodbpickle` package (used, obviously, by ZODB) work on Jython. It has a copy of the CPython pickle test cases so that exact failing test was still there to fail; I changed to the `super` call there as a temporary workaround. So far I haven't encountered it anywhere else.

The attached patch solves this issue by taking the same approach that CPython does (in typeobject.c) and not having object.__reduce__ call object.__reduce_ex__; instead they both call a common helper method. It re-enables the failing test in test_cpickle.py which now passes.

The second version of the patch plucks a couple more low-hanging fruit by mapping the exceptions from load/loads and enabling their tests.

Fixed as of https://hg.python.org/jython/rev/74811340dfe3