Strange crash issue on Windows w/ PyGTK, Cairo...

[bieffe62 at gmail.com]

On Mar 18, 6:20 am, CJ Kucera <p... at apocalyptech.com> wrote:
> Hello list!
>
> I'm having a strange issue, and I'm not entirely certain yet where
> the actual problem is (ie, Python, PyGTK, or gtk+), but I figure I'll
> start here.  Bear with me, this'll probably be a long explanation...
>
> I've been building an app which is meant to be run on both Linux and
> Windows.  It uses PyGTK for its GUI, and the main area of the app is
> a gtk.DrawingArea which I draw on using PyCairo.  I've been developing
> on Linux, and it works great on that platform, with no issues that
> I'm aware of.  When running on Windows, though, the app exhibits the
> following behavior:
>
>   1) When the .py of the main file which runs the application GUI first
>   gets compiled to a .pyc (ie: the first time it's run, or the first
>   time after .py modification), the application runs totally fine, with
>   no apparent problems.
>
>   2) Any attempt AFTER that, the application will start up, *start* to
>   do its data-loading, but then almost immediately crash with an
>   enigmatic "python.exe has generated errors and will be closed by
>   Windows."  When it does so, there is no output whatsoever to the
>   console that the application was launched from, and the crash doesn't
>   always happen in exactly the same place.
>
> The pattern remains the same, though - if the .pyc needs to be compiled,
> the application works fine, but if not: boom.
>
> I've been steadily stripping the program down to what I hoped would be a
> small, reproducible app that I could post here, and I do intend to do so
> still, but it's rather slow going.  For now, I was hoping to see if
> anyone's ever heard of behavior like this before, and might know what
> to do about it, or at least a possible avenue of attack.
>
> As I've been reducing the program down, I've encountered even stranger
> (IMO) behavior...  In one instance, changing a function name seemed to
> make the program work.  I took out the handler which draws my app's
> "About" box, and suddenly my problem went away.  Occasionally I would
> remove a function and the app would suddenly *always* fail with that
> Windows crash error, and I'd have to put the function back in.  Keep
> in mind, these are functions which *aren't being called anywhere.*
>
> Sometimes I could replace a function's entire contents with just "pass"
> and the app would suddenly behave properly, or not behave at all.
>
> It's almost as if whatever's doing the byte-compilation is getting
> screwed up somehow, and really small changes to parts of the file which
> aren't even being touched are having a huge impact on the application as
> a whole.  It's seriously vexing, and certainly the oddest problems I've
> seen in Python.
>
> 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+ 2.12.9-win32-2 (fromhttp://sf.net/projects/gladewin32, which is
> the version linked to from pygtk.org)
>
> The 2.6 Python stuff I've actually only tried on win2k so far, not XP,
> though given my history with this, I suspect that that wouldn't make a
> difference.
>
> Since gtk+ is the one bit of software that hasn't been swapped out for
> another version, I suppose that perhaps that's where the issue is, but
> it seems like Python should be able to at least throw an Exception or
> something instead of just having a Windows crash.  And having it work
> the FIRST time, when the .pyc's getting compiled, is rather suspicious.
>
> Anyway, I'll continue trying to pare this app down to one manageable
> script which I can post here, but until then I'd be happy to hear ideas
> from anyone else about this.
>
> Thanks!
>
> -CJ

It looks like some of the C extension you are using is causing a
segfault or similar in python
interpreter (or it could be a bug in the interpreter itself, but it is
a lot less likely).
I would suggest to fill the startup portion of your code with trace
statements to try to understand which module function is the
troublesome one, then go looking in the big tracking system of the
module, try the newest version and ask on the dedicated mailing list
if any.

Making a small script that cabn reproduce the bug is also a very good
idea, and will help speed-up the problem solution.

Ciao
-------
FB