skip@pobox.com wrote: > > mal> I wonder how the GC collector could "see" the type object before it > mal> has been initialized... since PyGtkTreeSortable_Type is a static C > mal> array and not a known PyObject until you add it to some Python > mal> dictionary as type object or use it for creating instances, it > mal> seems strange that the GC collector can reach out for it and get > mal> hit by the fact that it is not yet properly initialized. > > It is actually PyGtkWidget_Type that is not yet initialized when it is > placed in the bases tuple for one of its subclasses. GC traverses that > tuple, then dives into each element. It hits the PyGtkWidget_Type object, > whose ob_type field has not yet been initialized. The actual object whose > bases tuple is being traversed is (in all the crashes I encountered), > GdkDragContext. The ordering of the registration calls could perhaps be > reordered. Currently GdkDragContext is patched up before GtkWidget, its > base class. This code is generated by James Henstridge's wrapper code > generator, so perhaps he can maintain the necessary class hierarchy > relationships and insure that base classes are initialized before their > subclasses. Wouldn't it be easier to simply set the ob_type fields right at the start of the initGtk() function ? This is what I do for all my extensions and I've never seen any problems with it. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4