Index of /scratchpad/pygtk-zlib

[ICO]NameLast modifiedSizeDescription

[PARENTDIR]Parent Directory  -  
[TXT]README.html2009-03-23 10:51 1.7K 
[   ]iso_tileset_base.png.z2009-03-19 12:29 206K 
[TXT]pycairo-fix.patch2009-03-23 10:50 2.3K 
[TXT]run.py2009-03-19 23:00 828  

UPDATE:
Turns out this was a PyCairo issue, not a zlib one.  The change to how
zlib.decompress() was being called *did* alleviate the crashing
behavior, but it did so only incidentally.  The PyCairo fix looks to
be the one that fixes it for real.  I've uploaded the patch which fixes
it, though it's already in PyCairo CVS.



(original text follows)

This is either a memory allocation bug in Python's zlib, or PyCairo, on
Windows (Linux is unaffected).

In the Gfx class, if you specify bufsize while decompressing the zlib
data, the program runs fine, but if you don't, then it'll crash with
an enigmatic "python.exe has generated errors and will be closed by
Windows" message.  Note that the string returned from zlib.decompress()
is totally fine, and the error gets thrown later on in the program.
I had assumed this was a zlib issue, but I've yet to reproduce it
during anything other than this create_from_png() function, so it's
possible that PyCairo is what's getting in the way here.

On an XP system of mine, removing "import os" and "import sys" will
"fix" the problem.  On a win2k machine I can get rid of those imports and
still see the crash, though.  It's definitely a memory-clobbering
bug of some sort, I'm just not quite sure where.

Windows versions I can reproduce this on: XP and win2k
Python versions I've reproduced this on:
  Python 2.5.4 with:
    PyGTK 2.12.1-2-win32-py2.5
    PyGObject 2.14.1-1.win32-py2.5
    PyCairo 1.4.12-1.win32-py2.5
  Python 2.6.1 with:
    PyGTK 2.12.1-3-win32-py2.6
    PyGObject 2.14.2-2.win32-py2.6
    PyCairo 1.4.12-2.win32-py2.6
GTK versions used:
  gtk+ 2.12.9-win32-2 from the gladewin32 project
  gtk+-bundle 2.16.0-20090317_win32, from the other link on pygtk's
  download page