[issue3640] test_cpickle crash on AMD64 Windows build

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- versions: +Python 2.5.3 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue3640] test_cpickle crash on AMD64 Windows build

Tal Einat <[EMAIL PROTECTED]> added the comment: Will this be back-ported to 2.5.3? (please say yes...) -- nosy: +taleinat ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3640] test_cpickle crash on AMD64 Windows build

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: I've opened #3850 for the find_recursion_limit problem. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3640] test_cpickle crash on AMD64 Windows build

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Committed as r66390 and r66391. -- resolution: accepted -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> _

[issue3640] test_cpickle crash on AMD64 Windows build

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: By the way, this isn't caused by the present issue, but you'll notice that in the latest trunk, some tests in find_recursion_limit.py fail with an AttributeError instead of RuntimeError. This is likely caused by a PyDict_GetItem() call discard

[issue3640] test_cpickle crash on AMD64 Windows build

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Ah, ok. It's all fine, then. -- keywords: -needs review ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3640] test_cpickle crash on AMD64 Windows build

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: - cpickle.patch and find_recursion_limit.patch are for 2.6 - cpickle.patch-3.0.patch groups the two previous patches, adapted to 3.0. ___ Python tracker <[EMAIL PROTECTED]>

[issue3640] test_cpickle crash on AMD64 Windows build

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: The patch is fine, please apply. My only question is why the 3.0 patch integrates the find_recursionlimit change, whereas the 2.6 patch does not. -- assignee: mhammond -> amaury.forgeotdarc nosy: +loewis resolution: -> accepted ___

[issue3640] test_cpickle crash on AMD64 Windows build

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- nosy: +alexandre.vassalotti ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-b

[issue3640] test_cpickle crash on AMD64 Windows build

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Can someone have a look at this patch? It is not 64bit nor Windows specific; its goal is to reduce the size of local variables in batch_list(), which is easy to verify. The point is to check the correctness of the code, specially aroun

[issue3640] test_cpickle crash on AMD64 Windows build

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>: -- nosy: +jcea ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing l

[issue3640] test_cpickle crash on AMD64 Windows build

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Adapted the patch to python 3.0 Added file: http://bugs.python.org/file11228/cpickle-3.0.patch ___ Python tracker <[EMAIL PROTECTED]> __

[issue3640] test_cpickle crash on AMD64 Windows build

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Le samedi 23 août 2008 à 01:26 +, Mark Hammond a écrit : > cpickle.patch does make test_cpickle pass for me. FWIW, > find_recursionlimit.py now causes a segfault on 32 and 64bit Windows > (the comments imply a MemoryError is expected ther

[issue3640] test_cpickle crash on AMD64 Windows build

Mark Hammond <[EMAIL PROTECTED]> added the comment: Sorry for the initial noise - your analysis is correct, mine was flawed :) Simple recursion to a depth of 1000 does work fine on a 64bit build. cpickle.patch does make test_cpickle pass for me. FWIW, find_recursionlimit.py now causes a segfau

[issue3640] test_cpickle crash on AMD64 Windows build

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Here is an additional patch which adds a cpickle test to Misc/find_recursion_limit.py. It helps show that Amaury's patch does fix the issue. +1 for applying it. Added file: http://bugs.python.org/file11219/find_recursion_limit.patch

[issue3640] test_cpickle crash on AMD64 Windows build

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Attached patch removes the big array, items are saved when they are fetched from the container. I preserved the the special case when there is only one item. The patch does not merge cleanly into py3k, but the functions batch_list and b

[issue3640] test_cpickle crash on AMD64 Windows build

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: The problem comes from this local variable in batch_list() and batch_dict: PyObject *slice[BATCHSIZE]; and BATCHSIZE=1000... -- nosy: +amaury.forgeotdarc ___ Python tracker <[EMAIL PROTEC

[issue3640] test_cpickle crash on AMD64 Windows build

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: In my opinion this is a bug in cPickle. It is completely wrong to consume more than 3KB of stack space for each recursion level, and it should be fixed. -- components: +Library (Lib) priority: -> release blocker

[issue3640] test_cpickle crash on AMD64 Windows build

Changes by Mark Hammond <[EMAIL PROTECTED]>: -- assignee: -> mhammond keywords: +64bit ___ Python tracker <[EMAIL PROTECTED]> ___ ___ P

[issue3640] test_cpickle crash on AMD64 Windows build

New submission from Mark Hammond <[EMAIL PROTECTED]>: [from python-dev] I've found a recursion related crash in test_cpickle on 64bit builds. Specifically, the 'cPickleDeepRecursive' is causing a stack overflow, and the debugger tells me the actual recursion depth was 629 at the crash. The reas