Qt5/WinXP - Exception/try-catch in QApplication::notify [solved]
-
Hello,
I'm developing an application for an embedded device which runs on Qt4/ARM/Linux and additionally during development on Qt4/x86/Linux. Currently I'm porting it to Qt5/Windows for demonstration purposes - and noticed crashes:
bq. Microsoft Visual C++ Runtime Library
This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information.My Observation:
The crashes appear, when an exception is thrown in a slot. On Qt4/Linux we catch these exceptions by reimplementing the notify method of QApplication (see "You must reimplement QApplication::notify() and...":https://qt.gitorious.org/qt/qtbase/source/00da2e615e89c46affbc130b4df6148785724a23:src/corelib/kernel/qeventloop.cpp#L192). But on Qt5/Win this crash seems to appear before the exception reaches the notify method.
Pro Exceptions:
- According this warning in the "code":https://qt.gitorious.org/qt/qtbase/source/00da2e615e89c46affbc130b4df6148785724a23:src/corelib/kernel/qeventloop.cpp#L192, catching the exceptions in the notify-reimplementation is still supported.
- It seems that the exception support was improved in Qt5 (see "QUnhandledException":http://qt-project.org/doc/qt-5.0/qtcore/qunhandledexception.html, "ThrowFunction":http://qt-project.org/doc/qt-5.0/qtcore/qexception.html#details and "Exception Safety":http://qt-project.org/doc/qt-5.0/qtdoc/exceptionsafety.html
Con Exceptions:
- I found many bugs with the notice "Please note that in Qt 5 we'll just declare this undefined behaviour. That means crashing will be acceptable.":https://bugreports.qt-project.org/browse/QTBUG-26825
- Thiago wrote "You MUST catch any and all exceptions thrown before the slot returns. A slot that lets an exception leak through is malformed. The behaviour is undefined after that.":https://bugreports.qt-project.org/browse/QTBUG-27548?focusedCommentId=189062&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-189062
- Thiago wrote "Most of the Qt libraries are now built with exception support disabled. That means an exception travelling through it will probably mean a crash.":https://bugreports.qt-project.org/browse/QTBUG-27548?focusedCommentId=189081&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-189081
- and so on...
@Thiago: Are we really forced in Qt5 to wrap every SLOT in a try-catch block and perform the error handling (rException.EscalateToUser()) there? If this behavior was changed in Qt5, why don't I find a BIG warning in the documentation? Why is this "qWarning":https://qt.gitorious.org/qt/qtbase/source/00da2e615e89c46affbc130b4df6148785724a23:src/corelib/kernel/qeventloop.cpp#L192 not removed?
Or does this crash has another reason? I'm compiling on Windows with Qt SDK (Qt Creator 2.8.1, Qt 5.1.1, MinGW 4.8). Is it possible that the qt libraries from the packages is not (exception-) compatible? (see "MinGW: MixingCompilers":http://www.mingw.org/wiki/MixingCompilers)
Thanks in advance,
Charly
-
Hi,
You should rather ask this question on the interest mailing list (don't forget to subscribe first) you'll find there Qt's developers/maintainers (this forum is more user oriented) especially if you'd like to reach Thiago
-
Some intermediate results: I tried to reproduce it with a simple demo application. First I failed, but then I realized that this code causes a crash
@void SlotPerformer::SL_ThrowException()
{
QMessageBox oMsgBox;
oMsgBox.setText("Some output");
oMsgBox.exec();throw MyException();
}@
while this works fine:
@void SlotPerformer::SL_ThrowException()
{
{
QMessageBox oMsgBox;
oMsgBox.setText("Some output");
oMsgBox.exec();
}
throw MyException();
}@
This can't be the only problem... but it brings a little bit more light in this topic... (btw: on Qt4/Linux both snippets work fine) -
ok... MY FAULT!
I added this line to my profile file:
@QMAKE_LFLAGS += -static-libgcc@The GCC documentatation it says:
bq. There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc.
-
Great you found out !
Don't forget to update the thread title prepending [solved] so other forum users may know a solution has been found :)
-
But there is still the question, what Thiago's "posts":https://bugreports.qt-project.org/browse/QTBUG-27548?focusedCommentId=189081 would mean... because if he's right, we should think twice before using exceptions!
