qtcreator crashes stopping the application
-
- yes , i saw "SIG = 15", then kill app from from console
- myapp was "crashing" - that qtcreator says in output window
When trying to stop the application, the result is set to QProcess::CrashExit temporarily and updated whenever your process comes back with a proper exit. Your process doesn't come back with something better, so you get the "%1 crashed" response.
I don't really see this as a bug, at best the exit code should perhaps be part of the message.
-
hm, if qApp->exit(ExitHelperCode) is not the safe - that it should to be ?
that code works fine before qtcreator v.7 and works fine in my app as ubuntu service@abarmotov
That is not the current question. The question is: does the crash, misbehaviour or whatever the issue is go away if you remove that line? By now you could have given us that answer :) -
@abarmotov said in qtcreator crashes stopping the application:
if i remove qApp->exit, then:
- SIG = 15 and SIG = 2 printed IF i send that signals from console (or from kde task manager), but app continue working
- from creator "red" button crash my app still
i will try to check this behavior on another machine from new user with clean configs ...
-
fresh install on new user - same behavior
so need to know which signal creator sends to app on press "red" button - KILL, TERM, INT ...@abarmotov
I would suggest likelySIGTERMunder Linux, as per https://stackoverflow.com/questions/14137808/signals-sent-by-qtcreator-on-stop from 10 years ago....UPDATE
I was going to try your issue. Very unfortunately/scarily, the VirtualBox VM I use for Ubuntu has encountered a "critical error" while it was applying the latest Ubuntu patches (which I always do when firing up), and now will not get me into Ubuntu at all, and I don't know what to do. This has never happened before, and seems to leave me with an unrecoverable box :@ I am not a happy bunny.... Will get back to you if/when I can resolve this.... -
@abarmotov
Well most all signal handling is done by gdb, not Creator. What "crashes" when you do what? I certainly haveSIGINThandling in my application and works fine under gdb/Creator. (Though I admit I do not use Creator 7.x, and wouldn't use any of the latest stuff.) Have you tried disabling your program's signal handling temporarily to see if the "crashing" goes away?There should be a "debugger log window".: Window > Views > Debugger Log. This shows communicatins between Creator and gdb. That might tell you what communications happened that you are interested in.
Interesting blog in https://myprogrammingnotes.com/qt-creator-interact-debugger-gdb.html.
Code at https://github.com/qt-creator/qt-creator/blob/master/src/plugins/debugger/gdb/gdbengine.cpp. If you asked me to guess I'd hazard GdbEngine::interruptInferior()
No sign of any Linux
signals being used to gdb. If you find otherwise let me know! :) -
fresh install on new user - same behavior
so need to know which signal creator sends to app on press "red" button - KILL, TERM, INT ...@abarmotov
I have now recovered my Ubuntu VM successfully --- phew! :)I have pasted exactly your program. Run from Creator, press red Stop button. All is well, no crash. Application Output window:
13:48:42: Starting /home/jon/QtTests/build-signals-Desktop-Debug/signals ... SIG = 15 13:48:48: /home/jon/QtTests/build-signals-Desktop-Debug/signals exited with code 123As you can see it received a
SIGTERM, it was handled and it exited cleanly.Purely OOI, if run under Debug and click red Stop button program exits completely, cleanly, no crash, but does not visit the signal handler function. In this case the debugger is handling the Stop and doing whatever it does to stop its inferior process (the program being debugged) without sending it the
SIGTERMsignal.I am Ubuntu 20.04, Qt 5.12.5 (as supplied with Ubuntu) and Qt Creator 4.11.0. I therefore conclude that this is a Creator 7.x issue. Which does not surprise me....
-
@abarmotov
I have now recovered my Ubuntu VM successfully --- phew! :)I have pasted exactly your program. Run from Creator, press red Stop button. All is well, no crash. Application Output window:
13:48:42: Starting /home/jon/QtTests/build-signals-Desktop-Debug/signals ... SIG = 15 13:48:48: /home/jon/QtTests/build-signals-Desktop-Debug/signals exited with code 123As you can see it received a
SIGTERM, it was handled and it exited cleanly.Purely OOI, if run under Debug and click red Stop button program exits completely, cleanly, no crash, but does not visit the signal handler function. In this case the debugger is handling the Stop and doing whatever it does to stop its inferior process (the program being debugged) without sending it the
SIGTERMsignal.I am Ubuntu 20.04, Qt 5.12.5 (as supplied with Ubuntu) and Qt Creator 4.11.0. I therefore conclude that this is a Creator 7.x issue. Which does not surprise me....
-
@JonB yes, last creator crashing my app
good tested on 4.15.2 - "exited with code 123"
made bugreport https://bugreports.qt.io/browse/QTCREATORBUG-27619@abarmotov
OK, I had a read there, and posted my own finding.The responder there says it does not happen for him on Creator 7.0.2, which is what you have? Without them being able to repro nothing can be done. If you have not done so already, I would uninstall Creator completely and re-install. Maybe try a different version, like another 7.x or a 6.x? And if you have access to another machine that might help too.
-
@abarmotov
I cannot comment, but you can see the person who responded to your bug report says no problem under 7.0.2. You need someone/something reproducible. [Nonetheless: report your finding for 6.0.2. too, yet not for 4.15.2, in that bug report.]It could be something in your general "environment". If you are able to try to repro on another (preferably vanilla) machine or VM that would help your cause greatly....
-
@abarmotov
I cannot comment, but you can see the person who responded to your bug report says no problem under 7.0.2. You need someone/something reproducible. [Nonetheless: report your finding for 6.0.2. too, yet not for 4.15.2, in that bug report.]It could be something in your general "environment". If you are able to try to repro on another (preferably vanilla) machine or VM that would help your cause greatly....
