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.
Skip
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