Events after Object destruction
-
Hello!
I have a strange problem in a slow embedded system:
If I am fast enough, I can crash an application by double clicking a push button .
The reason behind this is, that in this application a window is closed as soon as someone is clicking the 'Ok' button. The window destruction is then taking place in the slot, that is linked to the 'pressed()' signal (the crash also occurs, if I use the 'clicked()' signal). What now happens is, that the first button press is shutting down the window doing a call to 'deleteLater(). While this is taking place, a the second button press is captured and placed in the event queue. I later get a message from the 'destroyed' signal, that the window is no longer existing but soon afterwards the application crashes, because the Event handler of QT is triggered by a mouse pressed event in the event queue. Because of this event he tries to access the object, which already has been deleted.
I already tried to place a 'QCoreApplication::removePostedEvents(sender()) into the slot that is called by the 'destroyed()' signal, but this did not make any difference.
The QT version I am using is 4.8.4. Has this maybe been solved in a later version?
Regards
Andreas
@anli said in Events after Object destruction:
Because of this event he tries to access the object, which already has been deleted.
Hmm... if an object is deleted via
deleteLater(), it should be removed from the event queue.the address is located in the QT event queue, where I do not have direct access to. Once the QT event handler finds an event there that says QPushButton with Address 0x1234 has been clicked, it tries to deliver this event to this push button instance, which is no longer there...
How is the button deleted? Also, are you using any threads in your application?
If you can't resolve your problem easily, consider replacing your window with a modal QDialog. This way, you don't need to delete the window manually, just let Qt take care of it.
The QT version I am using is 4.8.4. Has this maybe been solved in a later version?
Is it feasible to upgrade to Qt 4.8.7 at the very least?
-
Hello!
@kshegunov:
appEventFilter_c::eventFilteralways returns false so that the events are consumed by the event queue handler of QT, the relation between the two functions is, that there is a typo in my code example... They should both have the same name, I am sorry (the original names would have been too cryptic to have any meaning for you).@JKSH
As indicated in the code snipped above the object is deleted withdeleteLater()and thedestroyed()signal is linked with a slot, that prints aqDebug()message stating that the button has already been deleted when the crash happens.
Yes, threads are used but not in combination with GUI related tasks. They are used for writing data to SD Card or communicating with ICs connected to the SBC. All data, that is exchanged between the threads is locked by Mutexes.
The software we are talking about has a free configurable design via style sheets without any window decoration. This is why the software does not use QDialogs. -
Hello!
@kshegunov:
appEventFilter_c::eventFilteralways returns false so that the events are consumed by the event queue handler of QT, the relation between the two functions is, that there is a typo in my code example... They should both have the same name, I am sorry (the original names would have been too cryptic to have any meaning for you).@JKSH
As indicated in the code snipped above the object is deleted withdeleteLater()and thedestroyed()signal is linked with a slot, that prints aqDebug()message stating that the button has already been deleted when the crash happens.
Yes, threads are used but not in combination with GUI related tasks. They are used for writing data to SD Card or communicating with ICs connected to the SBC. All data, that is exchanged between the threads is locked by Mutexes.
The software we are talking about has a free configurable design via style sheets without any window decoration. This is why the software does not use QDialogs.@anli From your logs, I suspect that it's just as you say: The deleted button doesn't get properly removed from the event queue.
I'm not sure what's the best way forward though. The first thing I'd recommend is to upgrade to Qt 4.8.7 and see if the issue exists there.
-
Hello JKSH,
in the meantime we already tried this. We also changed the hardware platform to a faster one to get an idea, if this is maybe the reason, but also with QT 4.8.7 we get there the effect.
It seems to me as if the QWS window list does not get updated in time...
-
Hello JKSH,
in the meantime we already tried this. We also changed the hardware platform to a faster one to get an idea, if this is maybe the reason, but also with QT 4.8.7 we get there the effect.
It seems to me as if the QWS window list does not get updated in time...
@anli
You're still trying to sort out object deletion and signal/slot delivery etc., right?At this point if it were me, I would set up a new, standalone, minimal project, without worrying about "slow" or "embedded" etc., and just test what's going on in the simplest case, so that you understand. Having your full, complex, existing application code is just going to obscure whatever issue there is.
-
Might be a stupid workaround, but what happens when you, in your slot, set the PushButton to disabled, this should happe as the very first thing of course ?
-
For further information, I now attach a backtrace for the moment, when toolbutton is destroyed:
0 layout_n::manager_c::slotButtonDeleted layoutmanager.cpp 526 0x27eb70 1 layout_n::manager_c::qt_static_metacall moc_layoutmanager.cpp 243 0x28a4b4 2 QMetaObject::activate qobject.cpp 3540 0xd6c2f0 3 QObject::destroyed moc_qobject.cpp 149 0xd6dce8 4 QObject::~QObject qobject.cpp 843 0xd66c3c 5 QWidget::~QWidget qwidget.cpp 1705 0x38be4c 6 QAbstractButton::~QAbstractButton qabstractbutton.cpp 608 0x77284c 7 QToolButton::~QToolButton qtoolbutton.cpp 409 0x803c48 8 layout_n::toolButton_c::~toolButton_c layoutmanager.h 185 0x28b934 9 layout_n::toolButton_c::~toolButton_c layoutmanager.h 185 0x28b994 10 QObjectPrivate::deleteChildren qobject.cpp 1908 0xd68368 11 QWidget::~QWidget qwidget.cpp 1681 0x38bd90 12 QWidget::~QWidget qwidget.cpp 1705 0x38bec8 13 qDeleteInEventHandler qobject.cpp 4270 0xd6d858 14 QObject::event qobject.cpp 1175 0xd67384 15 QWidget::event qwidget.cpp 8846 0x39e564 16 QApplicationPrivate::notify_helper qapplication.cpp 4566 0x348428 17 QApplication::notify qapplication.cpp 4530 0x348260 18 QCoreApplication::notifyInternal qcoreapplication.cpp 947 0xd4e6b4 19 QCoreApplication::sendEvent qcoreapplication.h 231 0x34aee4 20 QCoreApplicationPrivate::sendPostedEvents qcoreapplication.cpp 1572 0xd4f950 21 QCoreApplication::sendPostedEvents qcoreapplication.cpp 1468 0xd4f548 22 QCoreApplication::sendPostedEvents qcoreapplication.h 236 0x3d2e68 23 QEventDispatcherQWS::flush qeventdispatcher_qws.cpp 164 0x3d2dbc 24 QCoreApplication::flush qcoreapplication.cpp 683 0xd4e0d0 25 QAbstractButton::mousePressEvent qabstractbutton.cpp 1101 0x773910 26 QToolButton::mousePressEvent qtoolbutton.cpp 710 0x804a90 27 QWidget::event qwidget.cpp 8371 0x39d230 28 QAbstractButton::event qabstractbutton.cpp 1085 0x77384c 29 QToolButton::event qtoolbutton.cpp 1162 0x8060cc 30 QApplicationPrivate::notify_helper qapplication.cpp 4566 0x348428 31 QApplication::notify qapplication.cpp 4108 0x3466e4 32 QCoreApplication::notifyInternal qcoreapplication.cpp 947 0xd4e6b4 33 QCoreApplication::sendSpontaneousEvent qcoreapplication.h 234 0x34af58 34 QETWidget::translateMouseEvent qapplication_qws.cpp 3539 0x3cbe08 35 QApplication::qwsProcessEvent qapplication_qws.cpp 2984 0x3c9d48 36 QEventDispatcherQWS::processEvents qeventdispatcher_qws.cpp 121 0x3d2b5c 37 QEventLoop::processEvents qeventloop.cpp 149 0xd4bc7c 38 QEventLoop::exec qeventloop.cpp 200 0xd4be10 39 QCoreApplication::exec qcoreapplication.cpp 1221 0xd4eec8 40 QApplication::exec qapplication.cpp 3823 0x34551c 41 main main.cpp 650 0x2192b4There you can see, that the mouse button press is captured by the QWS system around line 34, beeing then forwarded to the respective button, which should paint the button as pressed (line 25) and performs a flush of the event queue to get the paint event processed, which in this case also finds the 'delete later' (line 13), that has been posted to the event queue by the previous mouse button press event and performs this deletion. After leaving the flush function, it will continue to operate on illegal pointer variables, because its own object has already been destroyed
-
@JonB :
We tried it and currently do not get the problems there. We are currently trying to understand why.@J-Hilk :
We also tried this, but the second event got fired, before the button is disabled...@anli said in Events after Object destruction:
@JonB :
We tried it and currently do not get the problems there. We are currently trying to understand why.Alternatively, make a copy of your project and gradually simplify your code until the issue disappears.
-
@JonB :
We tried it and currently do not get the problems there. We are currently trying to understand why.@J-Hilk :
We also tried this, but the second event got fired, before the button is disabled...@anli said in Events after Object destruction:
We also tried this, but the second event got fired, before the button is disabled...
mmh, I'll like to throw in a new idea.
You should check, if your connection between button and slot is unique. If you called connect somewhere twice, than this could lead to the race condition. -
