Qt 5/QApplication – Linux – Sporadically segmentation faults clicking windows default close button
-
Hi everybody, hi Tobias Hunger,
regarding my last post:
"Linux / Window default close button / Segmentation fault"
I now discovered the relevant piece of code. Allocating QApplication dynamically e.g. with
QApplication *mainQApp = new QApplication(argc, argv);
is currently not save in Qt 5.
I checked some of the Qt 5 attached examples:
- ~/Qt5.0.2/5.0.2/gcc/examples/tools/contiguouscache
Apply the following changes to "main.cpp":
//QApplication a(c, v);
QApplication *a = new QApplication(c, v);//return a.exec();
return a->exec();Result: 58% Segmentation faults clicking windows default close button
- ~/Qt5.0.2/5.0.2/gcc/examples/widgets/layouts/basiclayouts
Apply the following changes to "main.cpp":
//QApplication app(argc, argv);
QApplication *app = new QApplication(argc, argv);//return app.exec();
return app->exec();Result: 54% Segmentation faults clicking windows default close button (File->Exit too...)
- ~/Qt5.0.2/5.0.2/gcc/examples/widgets/painting/basicdrawing
Apply the following changes to "main.cpp":
//QApplication app(argc, argv);
QApplication *app = new QApplication(argc, argv);//return app.exec();
return app->exec();Result: 6% Segmentation faults clicking windows default close button
- ~/Qt5.0.2/5.0.2/gcc/examples/webkitwidgets/fancybrowser
Apply the following changes to "main.cpp":
//QApplication app(argc, argv);
QApplication *app = new QApplication(argc, argv);//return app.exec();
return app->exec();Result: 4% Segmentation faults clicking windows default close button
A minimal QtGui application done with the Qt Creator and the changes
//QApplication a(argc, argv);
QApplication *a = new QApplication(argc, argv);
return a->exec();crashes most of the time while closing it with the windows default close button.
On contrast the windows default close button is save compiling against Qt 4.8.4... Always under the following basic conditions:
Ubuntu 12.04/Ubuntu Unity, gcc-Version 4.6.3, Qt5.0.2
I guess it must be a time-sensitive bug such as race conditions because it nearly never takes places using gdb.
Avoiding dynamic memory allocation with Qt5/QApplication currently helps me with my Qt 5 applications.
I guess Digia is interested in a real solution which I would prefer too.
Of course at first I wanted to post using the recommended bugtracker
http://bugreports.qt.nokia.com/Which welcomed me with the following charming ;-) message:
"It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet."Thanks
Michael - ~/Qt5.0.2/5.0.2/gcc/examples/tools/contiguouscache
-
it is: https://bugreports.qt-project.org
use code tags
there is absolutely no need to double post the "same issue":http://qt-project.org/forums/viewthread/28088/. You didn't even respond to the request in that thread!
-
Hi,
I posted about this issue a month ago. You can find the topic "here":http://qt-project.org/forums/viewthread/27196/. Basically, the QApplication pointer should be deleted before quitting. This solved the problem for me. However, it still think there's something peculiar happening, since I never noticed the segfault with the same project on Qt 4.6, but the solution is cleaner C++ so it didn't bother me much.
-
Hi raven-worx,
sorry for not hacking the page http://qt-project.org/forums/newtopic/10/
with the wrong link to your bugreports... ;-)
Michael
-
Hi raven-worx again,
you now that I responded immediately (which everybody can see checking the post)! Why do you state the difference...?
Of course it is the same issue but with a lot of additional information. I found /still find it's worth posting it again. Sorry for my different opinion... ;-)
And again I am not responsible for wrong links regarding bugreports on qt-project.org websites.
Did you ever think about the demotivating effect for all members of e.g. your last message.
Finally I am pretty sure you got my post even without code tags.
Michael
-
[quote author="michaelPT" date="1369667558"]
Of course it is the same issue but with a lot of additional information.
[/quote]
yep...still there is already a thread opened (by you with the same issue) and nothing prevents you from posting the additional information there.[quote author="michaelPT" date="1369667558"]
And again I am not responsible for wrong links regarding bugreports on qt-project.org websites.
[/quote]
Noone made you responsible for that... You were wondering about the message and i posted the correct link FOR YOU![quote author="michaelPT" date="1369667558"]
Did you ever think about the demotivating effect for all members of e.g. your last message.
[/quote]
It is demotivating for you when someone teels you not to double post? Then not a single forum on the planet is right for you. I never read a forum without such rule.[quote author="michaelPT" date="1369667558"]
Finally I am pretty sure you got my post even without code tags.
[/quote]
Yes sure i can .... but for you it is 2 characters to type. And YOU want something from others to help you, right? So a code without code tags is even more demotivating for me than a statement which points out that you shouldn't double post in my opinion.All these points (except the broken link) is well explained on the forum rules page you have posted.
-
Hi everybody,
checking the discussion started by "Guigui" one month ago (Segfault on QApplication exit) and answered by "MuldeR" I am again happy with QApplication and dynamic memory allocation.
It's indeed like this. Not returning allocated QApplication memory which was somehow tolerated in earlier Qt-Versions leads to segmentation faults in Qt5... which is of course fully C++ compliant.
Just to illustrate...:
[C++]
int main(int argc, char **argv) {
QApplication *mainQApp = new QApplication(argc, argv);simpleMainWindow *echtsimpleMainWindow = new simpleMainWindow();
echtsimpleMainWindow->setGeometry(440, 160, 1160, 460);QObject::connect(echtsimpleMainWindow, SIGNAL(globalQuit()), mainQApp, SLOT(
quit()));echtsimpleMainWindow->show();
//In case the main event loop exits calling quit() "exitInt" is 0
int exitInt = mainQApp->exec();
//Without deleting "echtsimpleMainWindow" currently no segmentation fault
//but just to make sure and according to C++...
delete echtsimpleMainWindow;
//deleting "mainQApp" according to C++ avoids any segmentation faults...
delete mainQApp;
//In normal case back to the operating system with "return 0;"
return exitInt;
}
[/C++]Michael