qtcreator crashes stopping the application

[abarmotov]

@JonB thanks for answer

1. application running without gdb - just "Run" with Ctrl+R
2. then i stop app with "red button" - in console creator prints "... myapp crashed"
3. as I remember, on version 6 it worked as it should - so it is a bug of v.7 or a new behavior ?

[JonB]

@abarmotov said in qtcreator crashes stopping the application:

as I remember, on version 6 it worked as it should - so it is a bug of v.7 or a new behavior ?

Ah, well don't you think that says it all?!

Experts may slap me down, but from what I have seen (in posts) I wouldn't touch Creator 7 or Qt 6 with a barge-pole.

• Did you at least try removing your signal handlers?
• Would you consider "downgrading" to Creator 6? What do you get out of 7 that you need?

[cristian-adam]

Please open a bug report at https://bugreports.qt.io/

Qt Creator crashing is always worth a bug report and ... it shouldn't happen. 😊

[J.Hilk]

If I understand the op correctly, that QtCreator is not crashing, but his application is when he presses the "big" red stop button above the integrated terminal inside QtCreator.

That's not unexpected, IIRC Creator sends SIGTERM and/or SIGKILL to the application process when that button is pressed and thats not a clean exit for any program.

[JonB]

@abarmotov said in qtcreator crashes stopping the application:

application running without gdb - just "Run" with Ctrl+R

Now that I understand you were never running under debugger, which I thought you were: have you indeed tried running it under debugger (Debug button)? If your code really is misbehaving in its signal handlers you may be able to debug that successfully.

[abarmotov]

@JonB said in qtcreator crashes stopping the application:

Would you consider "downgrading" to Creator 6? What do you get out of 7 that you need?

1. I noticed that v.7 is faster in clang code analysis, so not planned back to v.6
2. qtcretor not crasing - but my app is
3. I think that v.6 gave time to myapp to work out on the SIGTERM signal, but now it does not
4. will make bugreport

[JonB]

@abarmotov said in qtcreator crashes stopping the application:

I think that v.6 gave time to myapp to work out on the SIGTERM signal, but now it does not

Like I last wrote: have you at least tried Debug instead of Run to see what happens?

[abarmotov]

i run under debugger - no crashes in my app

but gdb not enters in my signal handler too - maybe creator(gdb) intercepted it

then i try to kill myapp outside from console - creator saw it, then show popup window about signal and then i continued - app exits with no error

[JonB]

@abarmotov
Try putting a breakpoint on the signal handler function.
IIRC the signal first goes to gdb, then you have to continue for it to be delivered to program.
The point to discover is whether your signal handler ever gets hit at all --- even an fprintf(stderr) or qDebug() as first statement in handler might tell you.

[abarmotov]

somehow no breakpoint hit in signal

[JonB]

@abarmotov
Need to determine if @J-Hilk's

IIRC Creator sends SIGTERM and/or SIGKILL to the application process when that button is pressed

is right. Like I just wrote, put some fprintf(stderr) or qDebug() as first statement in handler.

BTW, do you want to show what code you actually do have in your signal handler(s)?

[abarmotov]

1. where is printf in handler
2. i will show code little latter, and attach to bugreport - there is no secret, but i need to remove excess code

[JonB]

@abarmotov said in qtcreator crashes stopping the application:

where is printf in handler

What do you mean by this? Unless you are ignoring the signals you have specified a function to be executed when the signals arrive. That is a "handler" function. You have some code in that function? I am suggesting you might put a fprintf(stderr, "Caught signal!\n") or qDebug() << "Caught signal!" as the first statement in whatever you have, so that we might see whether it is ever hit (in case breakpoints aren't working right).

[abarmotov]

1. create new app in creator
2. add some little code "signalhandler"
3. run it Ctrl-R
   4.1 kill from creator
   4.2 kill from outside konsoles

#include "mainwindow.h"
#include <QApplication>
#include <unistd.h>
#include <signal.h>

void signalhandler(int sig) {
	printf("SIG = %i\n", sig);
	int ExitHelperCode = 0;
	if (sig == SIGINT || sig == SIGTERM) ExitHelperCode = 123;
	else if (sig == SIGUSR1) ExitHelperCode = 124;
	qApp->exit(ExitHelperCode);
}

int main(int argc, char *argv[])
{
	signal(SIGINT,  signalhandler);
	signal(SIGTERM, signalhandler);
	QApplication a(argc, argv);
	MainWindow w;
	w.show();
	return a.exec();
}

[JonB]

@abarmotov

• Did you ever get to see the output from the printf("SIG = %i\n", sig); which is there?

• Comment out the qApp->exit(ExitHelperCode);. Does that have any effect on the "crash" you report? And btw how do you know your app was "crashing", given that it was supposed to exit?

It all still boils down to whether that signal handler function is being hit at all when you press the "Stop" button from Creator.

You might also try

signal(SIGINT,  SIG_IGN);
signal(SIGTERM, SIG_IGN);

instead as your first two lines in main().

[abarmotov]

1. yes , i saw "SIG = 15", then kill app from from console
2. myapp was "crashing" - that qtcreator says in output window

[JonB]

@abarmotov
Yes, that's SIGTERM. I think you are saying it hit your printf("SIG = %i\n", sig); line, so we know it went into sighandler()? Then like I said try commenting out the qApp->exit(ExitHelperCode);, it may not be possible/safe to call that from within a signal handler.

[andr]

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.

[abarmotov]

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

[JonB]

@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 :)