Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.10.1, 5.12.3
-
None
-
MSVC 2017 compiler
Description
I reduced the following example to the absolute minimum. So the nested QTimer::singleShot is indeed necessary. The actual code where I engaged this bug is much more complicated, with lock_guard's and Q_ASSERT and multiple threads.
Here I enqueue one lambda to the event loop which does nothing more than placing a function call to f on the event loop and calling f directly after that.
I expect the event loop to handle one event after the other. So function f should be called once and after it returns to the event loop it should get called a second time.
What I do not expect is, that the function f gets entered twice before returning once.
But this is what actually happens. The call to qFatal seems to process events.
// console output of example program, if you ignore the fatal dialogs
1 - enter f
2 - inside f
1 - enter f
2 - inside f
3 - leave f
3 - leave f
I noticed this bug in another project, when I got an assertion and the dialog popped up and I pressed ignore, because the assertion failure was not critical to me, but the unexpected event processing crashed my program.
It is possible, that this problem is Windows specific. But I don't expect QT functions to process events in general. If I want to do that, I would call QCoreApplication :: processEvents directly.
#include <QCoreApplication> #include <QTimer> void f() { qInfo("1 - enter f"); qFatal("2 - inside f"); qInfo("3 - leave f"); } int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); QTimer::singleShot(0, [] { QTimer::singleShot(0, f); f(); }); return a.exec(); }