https://bugs.kde.org/show_bug.cgi?id=491769
--- Comment #3 from David Faure <fa...@kde.org> --- Oh, you said TransactionItemView itself is down to a QObject. Then it needs to disconnect() the connect to the destroyed signal. This is likely a regression coming from the port from SIGNAL()/SLOT() to &Class::slot syntax. The latter syntax creates this kind of bug because the connection remains valid until full destruction, while the SIGNAL/SLOT solution was based on virtual methods so no slot was called in a partially destroyed receiver. This means storing the return value of the connect() statement into a QMetaObject::Connection member variable, and using it to disconnect in the destructor. -- You are receiving this mail because: You are the assignee for the bug.
