The attached 2.x-written protocol 0 pickle file cannot be loaded by Python 3.2 or 3.3, though it loads successfully in 2.x.

Code used to load:

data = pickle.load(open('test.bin', 'rb'))

Error:

Traceback (most recent call last):
  File "load_it.py", line 4, in <module>
    data = pickle.load(open(sys.argv[1], 'rb'))
ValueError: invalid literal for int() with base 10: "273\n(g8\nS'uint64_t'\np274\ntp275\nsS'Module'\np276\n(g45\n(g39\nS'objc_module'\np277\nNtp278\ntp279\nsS'mach_msg_trailer_size_t'\np280\n(g4\ng190\ntp281\nsS'uint_fast16_t'\np282\n(g8\nS'uint16_t'\np283\ntp284\nsS'pthread_m"

The failure occurs on Ubuntu Natty. This does not appear to be the same issue as #6137.

AFAIK the data contains no classes: just dictionaries, tuples, lists, strings and numbers.

I also noticed that in the file there are numerous previous integer values in a similar context, which were parsed without error. For example, if you look at the test.bin file in an editor, the failure occurs while parsing line 515. Notice the similar constructs at lines 510, 507, 504 etc.

In _pickle.c, the load_put function calls _Unpickler_Readline, which may prefetch data and place it after the line read in with "readline". load_put then calls PyLong_FromString, which doesn't like the trailing data after the '\n'.

Maybe just use PyOS_strtol instead? Alternatively, replace the newline with a null byte.

First, the patch calls PyOS_strtol while a Py_ssize_t should be decodable. However, the dump phase (in memo_put) coerces the memo size to long as well, so this shouldn't be a problem in real life.

Second, the patch needs a test.

Also, please click on the "resolution" link for meaning of the various possible "values". "Accepted" is only to be used when something has been positively reviewed.

I can add a test, using the data attached to the ticket, but like the marshal case we discussed before, it might be several KB of data, which I would incorporate into the tests using a similar approach to the one I used for marshal. (This data has been shrunk from a much larger data set, but I can't easily make it any smaller.)

I've no idea why I changed the resolution, I don't normally do this. Probably a case of brain-fade :-(

Ok, the patch is not correct. The core issue is that _Unpickler_Readline should always return a \0-terminated string, but sometimes it doesn't; this issue should be fixed instead of working around it in some other function.

I confess I'm not familiar enough with the pickle module internals to be sure of putting in the right fix quickly. I will take a look at _Unpickler_Readline when I get a chance, if someone doesn't beat me to it :-)

New changeset c47bc1349e61 by Antoine Pitrou in branch '3.2':
Issue #12687: Fix a possible buffering bug when unpickling text mode (protocol 0, mostly) pickles.
http://hg.python.org/cpython/rev/c47bc1349e61

New changeset 6aa822071f4e by Antoine Pitrou in branch 'default':
Issue #12687: Fix a possible buffering bug when unpickling text mode (protocol 0, mostly) pickles.
http://hg.python.org/cpython/rev/6aa822071f4e

Fixed with a test.