If gzip.py reads a mangled/truncated file and leaves the file pointer at EOF, the zlibmodule will crash when it calls 'flush' (PyZlib_unflush()). I've traced through zlib a bit, and I think the problem is that the 'avail_in' slot of the decompression struct is left uninitialized. The problem can be made to go away by setting that slot to zero in either PyZlib_decompressobj(), or in PyZlib_unflush() itself. However, I'm not familiar enough with the code to know if there's some other reason the slot contains garbage. Reproduction: >>> open ('x.gz', 'wb').write ('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00') >>> import gzip >>> gzip.GzipFile ('x.gz', 'rb').read() Segmentation fault (core dumped) [the above data is simply a small gzip file truncated after the zero-terminated filename]
Logged In: YES user_id=80475 On WinME, I can confirm segfaults in Py2.3 and Py2.4. Andrew, I think this is your baby. BTW, the OP's example would make an excellent testcase.
Logged In: YES user_id=11375 If flush() is called without an intervening .decompress() call, some fields in the zlib structure are left uninitialized. I'll check in a test and fix. The same problem exists with compression objects, but calling flush() doesn't result in a segfault. Perhaps the zlib code for deflate() doesn't end up dereferencing the garbage fields; I'll check in a fix anyway.
Logged In: YES user_id=11375 Applied to 2.4 and 2.3 maintenance branches. (2.2 is probably affected, too, but I won't bother to backport the fix.) Closing bug. Thanks for reporting the problem!
