On 7/16/2007 2:36 PM, Phil Thompson wrote:
This will be fixed in tonight's PyQt snapshot.
The proxy created to handle the signal was being incorrectly reused by a new
QObject created at the same address as the one the proxy was created for.
Because there is no event processing going on, the proxy was not getting
deleted - because it was waiting for a deleteLater() to be acted on.
I now get other crashes: from the debug, it seems like an instance of
PyQtProxy which is already deleted is still part of the global list
(uniproxies). Using debug builds of MS CRT, C++ instances which are
deleted are filled with 0xFEFEFEFE, so I'm pretty sure of this symptom.
I had a look at your fix, and you moved the code to remove the PyQtProxy
instance from the global list to the new disable() slot. Thus, if an
instance of PyQtProxy is deleted directly without going through the
slot, it will still be presente in the global list.
I copied the list removal code back into the destructor (keeping a duped
copy in the disable() slot), and it seems to work.
Do you agree on this fix? Testcases are really hard and tiresome to
extract so I'd rather avoid it if it's not really really necessary...
--
Giovanni Bajo
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
