> You could look at the call to PyObject_GC_UnTrack() in > sipWrapper_dealloc(). I don't think it's the same problem, but there may be > similarities.
As far as I can tell, PyObject_GC_UnTrack just says that the GC shouldn't call the traverse functions while you're destructing the object--but what I think I need to do is zone off garbage collections to be limited to one thread. Now that I've looked at the code a bit more, I'm thinking maybe the sipOMRemoveObject immediately before td_dealloc might have something to do with my crash. The comment above it says "By removing it from the map first we ensure that a new Python object is created" -- maybe if a new Python wrapper is constructed for my disappearing object, then the crash happens when the new wrapper is accessing the old object? I'm still trying to figure it out. BTW, the top of my crash stack is _wxcore.pyd!sipwxEvtHandler::~sipwxEvtHandler() sip.pyd!sipWrapper_clear(_sipWrapper * self=0x077f0ab0) sip.pyd!sipWrapper_dealloc(_sipWrapper * self=0x077f0ab0) python25.dll!subtype_dealloc(_object * self=0x077f0ab0) python25.dll!dict_dealloc(_dictobject * mp=0x07b09390) sip.pyd!sipWrapper_clear(_sipWrapper * self=0x0779ac30) python25.dll!subtype_clear(_object * self=0x0779ac30) python25.dll!delete_garbage(_gc_head * collectable=0x03d6dce0, ... ) python25.dll!collect(int generation=0) Line 855 C python25.dll!_PyObject_GC_Malloc(unsigned int basicsize=16) python25.dll!_PyObject_GC_New(_typeobject * tp=0x1e1bd4d0) python25.dll!PyWrapper_New(_object * d=0x00b425d0, _object * ..) ... _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
