Den 07-01-2015 kl. 11:30 skrev Nuno Santos: > Hi Igor, > > Ops… You are right, it is not static. > > I have tried your suggestion but now it crashes everytime I close the > app and I can’t even get a stack trace like before. If I run it on > debug, it points me to assembler code. Not anything I can really point to. > > Regards, > > Nuno > >> >> On 07 Jan 2015, at 10:19, Igor Mironchik <igor.mironc...@gmail.com >> <mailto:igor.mironc...@gmail.com>> wrote: >> >> On Wed, 07 Jan 2015 13:01:32 +0300, Nuno Santos >> <nunosan...@imaginando.pt <mailto:nunosan...@imaginando.pt>> wrote: >> >>> Yes, >>> >>> int main(int argc, char **argv) >>> { >>> QGuiApplication app(argc, argv); >>> >>> ... >>> >>> return app.exec(); >>> } >> >> No. Here QGuiApplication is not static. Then in your app the situation >> is the next: QGuiApplication destroyes before your Manager. But any >> QObject-derived class must be created after QApplication and destroyed >> before QApplication. May be this is the reason of your crash. >> >> Make QGuiApplication static. For example: >> >> static QSharedPointer< QApplication > application( int argc = 0, char >> ** argv = 0 ) >> { >> static QSharedPointer< QApplication > app( >> new QApplication( argc, argv ) ); >> >> return app; >> } >> >> and in main() >> >> QSharedPointer< QApplication > app = application( argc, argv ); >> >> before any QObject... >> >>> >>> >>>> On 07 Jan 2015, at 09:54, Igor Mironchik <igor.mironc...@gmail.com >>>> <mailto:igor.mironc...@gmail.com>> wrote: >>>> >>>> Hi, I have one question: is QApplication static too?
This probably doesn't make any difference. What this does is to defer the destruction of the QApplication object until the main() method is done, which effectively makes sure you delete QApplication last. EXCEPT that it doesn't work :) Because you can't guarantee that there are no QObject derived static objects from other methods that are deleted after. Forget this and stay with a normal heap allocated QApplication object. If this causes any trouble, you need to find the reason for it instead of trying a workaround that at best makes the problem a bit less likely to surface. There are (at least) three things I do for random crashes: 1) Build on Linux and run it in valgrind if you can. 2) Run it in a debugger where you have the Qt sources registered so you get backtraces that have meaning. 3) Comment out creating as many objects as you can so the problem becomes visible with as few as possible. This minimizes your object interactions so the problem is easier to track. And if you're using threads: 4) Replace all start() with run() and pray your problem still exist. I hope this helps. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
