Design issue with custom qcr::messageHandler
The problematic part in this void qcr::messageHandler` is the call of QMessageboxes like for example
link to source file / main branch
QMessageBox::warning(QApplication::activeWindow(), qAppName(), msg);
or
QMessageBox::critical(
QApplication::activeWindow(), qAppName(),
"Sorry, you encountered a fatal bug.\n"
"The application will terminate.\n"
"Please save the log file and inform the maintainer.\n\n"
"Error:\n"
+ msg
+ "\n"
#ifndef QT_NO_DEBUG
"Context:\n"
+ ctx.function + "\n"
#endif
);
Calling MesssageBoxes looks like a harmless thing to do, but it leads to a big problem when it is done by a worker thread, see:
https://doc.qt.io/qt-6/thread-basics.html
GUI Thread and Worker Thread
...
The Qt GUI must run in this thread. All widgets and several related classes, for example QPixmap, don't work in secondary threads. A secondary thread is commonly referred to as a "worker thread" because it is used to offload processing work from the main thread.
...
Now, not calling a widget from a worker thread seems pretty easy to follow. However: This custom messagehandler of libqcr replaces the Qt default MessageHandler and will handle all these qDebugs, qWarning, qInfo etc. These do not normally try to spawn MessageBoxes, since qDebug is part of QtCore and not QtWidgets. Therefore it is hard to expect this behavior (unintuitive) and further more this breaks the separation of QtCore (qDebug) and QtWidget (qMessageBox). By this messageHandler QtWidgets effectively "sneaks" into Steca Core without being noticed. This is from my point of view very problematic.
Even more troublesome is that the crash does not lead to its origin. The trace simply points you to the wait function for std::future or Qt::Future while the actual problem lies in custom message handler of libqcr (In this current example of Steca this leads one to study the yield methods of lazydata).
I think this should outline the problem Ive found very clearly.
Now my suggestion: At least one should makes sure that this kind of custom messagehandler will be not executed when called from a worker thread (if this is possible). However in my personal opinion this is not enough. Like stated: pulling QtWidgets into qDebug, qInfo, qWarning etc is problematic by its nature and it would be best to remove this completely.
Additional Thoughts: After Ive spent almost a full week on this one Steca issue Ive found the origin and reported it via this issue. Bust this will most likely solve (or explain at least partially) also other things which Ive noticed in Steca like for example that under windows qWarnings qDebugs do not work at all. At least after Ive learned about this custom message handler and what it does I have an idea what can could go wrong there. Also Joachim: You told me once, that you also had the experience that qDebug qWarning etc do not always work correctly. I do not know where you made this experiences, but if you made this experiences using libqcr (with this messagehandler) then this could also an explanation for this.
We should have discussion about this in team, here or in our monday meeting @j.wuttke @a.nejati @m.svechnikov