[Guido]
> It's not impossible that the bug is actually in the debug mode macros,
> but I'd rather not ship code that's instable in debug mode -- that
> defeats the purpose.
I *suspect* the difference wrt debug mode is right where it's blowing up:
static void
gc_list_remove(PyGC_Head *node)
{
node->gc_prev->gc_next = node->gc_next;
node->gc_next->gc_prev = node->gc_prev;
#ifdef Py_DEBUG
node->gc_prev = NULL;
node->gc_next = NULL;
#endif
}
That is, in debug mode, the prev and next fields are nulled out, but not in
release mode.
Whenever this thing dies, the node passed in has prev and next fields that
*are* nulled out. Since under MS debug mode, freed memory is set to a very
distinctive non-null bit pattern, this tells me that-- most likely --some
single node is getting passed to gc_list_remove *twice*.
I bet that's happening in release mode too ... hang on a second ... yup! If
I remove the #ifdef above, then the pair test_weakref test_xmllib dies with a
null-pointer error here under the release build too.
and-that-ain't-good-ly y'rs - tim
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