OK, Christmas is over, and I didn't really get a chance to look at it much.

However, some preliminary testing of the zlib library suggests that it is _not_ in zlib. A c program that does the same compress/decompress of random data using steadily increasing block sizes does not show the same fault...

I've noticed what might be a potential problem in the inflateInit2 call in PyZlib_decompressobj. The next_in and avail_in are not being initialized before it's called. The zlib manual says they should be init'ed because deflateInit will attempt to determine the compression method if it can. I'm not sure why this hasn't tripped already... does PyObject_New zero memory when it allocates things?

I also think I've found the main problem... the PyZlib_objdecompress routine's main decompression loop thinks decompression is compelete when all available input has been processed. However, it is possible that all available input has been processed but there is more pending output. The code as it stands does correctly allocate more space when this occurs, but the loop terminates without calling inflate one more time.

I'm putting together a patch tomorrow. Right now I'm going to bed...