Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7358
___
___
Python-bugs-list mailing list
Roundup Robot added the comment:
New changeset a025b04332fe by Serhiy Storchaka in branch '2.7':
Issue #7358: cStringIO.StringIO now supports writing to and reading from
http://hg.python.org/cpython/rev/a025b04332fe
--
nosy: +python-dev
___
Python
Changes by Serhiy Storchaka storch...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7358
___
Serhiy Storchaka added the comment:
Thank you for review and enlightenment Gregory. Here is an updated patch which
doesn't change an ABI.
--
Added file: http://bugs.python.org/file28951/cStringIO64_2.patch
___
Python tracker rep...@bugs.python.org
Gregory P. Smith added the comment:
Suggested workaround: use io.BytesIO instead of cStringIO.
comments on the patch... in short: your patch is changing an ABI and isn't
suitable for a maintenance release.
I'm not sure how much we can usefully do to cStringIO in a maintenance release.
I'd
Antoine Pitrou added the comment:
Not making cStringIO 64-bit compatible is one thing. But we can still fix the
crashes by detecting an overflow before it happens ;)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7358
Serhiy Storchaka added the comment:
Suggested workaround: use io.BytesIO instead of cStringIO.
Well, maybe we can replace cStringIO by io.BytesIO in cPickle (and other
places).
comments on the patch... in short: your patch is changing an ABI and isn't
suitable for a maintenance release.
Gregory P. Smith added the comment:
Include/cStringIO.h is public and the name of the structure PycStringIO lacks
an _ which implies that it is public.
There appear to be a few references to it in external projects doing some
searching. A (very old) version of twisted/protocols/_c_urlarg.c
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
components: +Extension Modules, IO -Library (Lib)
nosy: +serhiy.storchaka
stage: - needs patch
versions: -Python 2.6
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
Here is a patch.
--
keywords: +patch
stage: needs patch - patch review
Added file: http://bugs.python.org/file28880/cStringIO64.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7358
Gilles Louppe added the comment:
Hi,
Any solution regarding that issue? We are currently encountering the exact same
bug when pickling too large objects.
Best,
Gilles
--
nosy: +Gilles.Louppe
___
Python tracker rep...@bugs.python.org
Martin v. Löwis added the comment:
Gilles: it's really puzzling that you run into the issue. This is an assert, so
in a regular build of Python, it should never trigger. Instead, it should
trigger only in a debug build. Why are you running a debug build?
--
Martin v. Löwis added the comment:
Antoine: if you look at
http://svn.python.org/view/python/branches/ssize_t/Modules/cStringIO.c?revision=41731view=markuppathrev=42382
you'll notice that IOobject and Iobject have pos and stringsize as int, whereas
Oobject has it as Py_ssize_t. This must have
Antoine Pitrou pit...@free.fr added the comment:
The issue looks quite clear: cStringIO.write() asserts that the required
storage size is less than INT_MAX. Therefore, in all likelihood, the pickle
dump is simply larger than 2GB.
Now, the cStringIO structures seem 64-bit safe, so the
14 matches
Mail list logo
