When I use zlib.decompress to decompress a string where the result would
be >1 GB I get
SystemError: Objects/stringobject.c:4089: bad argument to internal function

I tracked that down to an int overflow of r_strlen in PyZlib_decompress.
Using Py_ssize_t instead of int solved this for me (on 64bit Linux).

The patch is against
python/trunk/Modules/zlibmodule.c
Revision: 56476

Kind regards,
Peter

I trust that there's a problem, but this can't be right -- the address
of r_strlen is passed to PyArg_ParseTuple corresponding to an 'i' format
letter.  That will never do.

You are right. The format should be 'l'. I overlooked that. In my case the
optional 'buf_size' parameter of 'decompress' is not used anyhow.
Shall I change the patch accordingly?

It work well for me and I now checked the code of PyArg_ParseTuple
(Python/getargs.c) to see what happens. As far as I understand, the given
pointer is casted to a pointer to int if the format is 'i' (line  630) . On
a 64 bit machine this leads to a downcast from a (64 bit) long to a (32 bit)
int, which is OK AFAIK, but I could be wrong.

Thanks for pointing that out,
Peter
2007/11/2, Guido van Rossum <report@bugs.python.org>:
>
>
> Guido van Rossum added the comment:
>
> I trust that there's a problem, but this can't be right -- the address
> of r_strlen is passed to PyArg_ParseTuple corresponding to an 'i' format
> letter.  That will never do.
>
> ----------
> assignee:  -> nnorwitz
> nosy: +gvanrossum, nnorwitz
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1372>
> __________________________________
>

The correct format for a Py_ssize_t is 'n' (at least in the trunk, I
don't have the 2.5 branch handy but I imagine it's the same).

We can figure out the patch from here.

Fixed in r59081 and r59080

py3k will follow at the next svnmerge