On Tuesday 17 July 2007 2:34 pm, Giovanni Bajo wrote: > 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.
Understood. > 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... I can only see one place that a PyQtProxy is explicitly deleted. Can you try changing the "delete up" in sipQtDestroyUniversalSlot() to "up->disable()" instead of your fix. Phil _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
