Margarita Manterola wrote: > I probably screwd up, because it didn't work. This is what I was left with:
My code was not meant to be run verbatim, sorry I didn't make that clearer. For example, PyImport_Import takes a PyObject * argument, not a C string, use PyImport_ImportModule instead. This is why you got a crash when you tried to use the returned object (likely NULL or garbage). > // error checking elided for brevity Please don't "elide error checking for brevity" in the code you're using for actual testing, include it! If you're not sufficiently familiar with Python/C, at least read up sections on reference counting and error checking of "Embedding and extending" manual. >> Maybe you're seeing a weird corner case of >> http://bugzilla.gnome.org/show_bug.cgi?id=546802 which is known to cause GC >> to prematurely break cycles which it shouldn't. I'd try applying the fix >> for that bug, maybe it helps. > > I applied that patch and it seems to have worked. No more segfaults, > no calls to the tooltips_destroy. > > However, I have no idea what the patch does and if the bug is really > fixed by this, or it's just a coincidence (being that it's a bug > related to what might happen if GC runs, it's very difficult to > check). The bug causes objects reachable only from GTK be erroneously trashed by the GC. The details are hard to understand because they involve interaction between two reference-counting systems (those of GObject and Python), but that would be the gist of it. It has bitten me in the past and I've reported a duplicate of it. What you saw could well be caused by that bug, but it'd be a good idea to verify it, for starters by confirming that the bug is caused in the GC, and then that the fix for 546802 fixes it. _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
