Neil> In other words the GC is finding a tuple object that contains an
Neil> element with a funny looking address (data segment?) and an
Neil> op_type of NULL.
Neil,
I'm not sure if the funny looking address is a red herring or the key to the
crime. I tried running with a breakpoint set in getBaseDictionary. The
first couple times, the type parameter looked like
$26 = (PyExtensionClass *) 0x80e7f60
$27 = {ob_refcnt = 2, ob_type = 0x80e7f60, ob_size = 0,
tp_name = 0x80d7138 "ExtensionClass", ...}
$28 = (PyExtensionClass *) 0x80e8060
$29 = {ob_refcnt = 1, ob_type = 0x80e7f60, ob_size = 0,
tp_name = 0x80d7209 "Base", ...}
The third time it looked like
$30 = (PyExtensionClass *) 0x4019f120
$31 = {ob_refcnt = 1, ob_type = 0x80e7f60, ob_size = 0,
tp_name = 0x4019dab2 "GObject", ...}
The difference between the first two calls and the third one is that the
first two objects are defined in ExtensionClass.o, which I currently
statically link into the interpreter. The Gtk/GObject stuff is dynamically
loaded into the running executable, so it's not surprising that it winds up
at a wildly different address than the ExtensionClass stuff. My current
best guess is that whatever object the tuple is referring to is declared
static in the dynamically loaded Gtk stuff and has no business getting
reclaimed by the collector. Sounds like a missing Py_INCREF somewhere.
At the earliest point I've been able to check that object so far, its
ob_type field is NULL.
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