How can I catching SIGINT signal in mingw gdb?

[Tancen]

I want to handle signals in my callback proc, yet the signal was expensed by gdb.
Even if with command "handle SIGINT nostop pass".
Code like:

void handleSignal(int sig)
{
    ...
}

signal(SIGINT, handleSignal);

[JonB]

@Tancen
What do you mean by "catching"? Clarify what you want and what is actually happening? Your nostop means gdb will not stop, is that what you want? Or do you mean stop to break into gdb? Or ignore? Or what do you want? nostop pass is effectively a "no-op": signal does get passed to program, gdb does not stop, so it's just as if gdb were not there.

[Tancen]

@JonB i want to handle signals in my callback proc, yet the signal was expensed by gdb.
code like:
void handleSignal(int sig)
{
...
}

signal(SIGINT, handleSignal);

[JonB]

@Tancen
OK, now I understand. You are sending SIGINT to your program, you want to allow your code to handle it, but gdb doesn't seem to pass it on.

http://mingw.5.n7.nabble.com/Sending-SIGINT-to-process-inside-gdb-td13124.html reports something that looks similar. But that's 2008, I doubt if it couldn't be done we wouldn't have heard about it for 10 years!

I agree it sounds like handle SIGINT nostop pass should do the job. If you say it does not, put it back to default (restart gdb) and after gdb intercepts the signal, can't you just continue, allowing the signal to be passed on to the program? Check your gdb settings, and that your program really does have that signal handler installed for that signal? You could also try the actual gdb signal command to send the signal, so you're sure it's being sent. The code you show seems to install a signal handler, I don't see the code or whatever you are doing to raise the signal?

And if what you mean is, you're attempting to "raise" the signal via Ctrl+C really, then you should tell us, and look at say https://stackoverflow.com/questions/711086/in-gdb-on-mingw-how-to-make-ctrl-c-stop-the-program Or just https://stackoverflow.com/questions/7794708/terminate-program-hitting-ctrlc-within-gdb, https://stackoverflow.com/questions/6008140/how-to-debug-programs-using-signals

[Tancen]

@JonB
thank you.
follow my code:

#include <QCoreApplication>
#include <signal.h>
#include <qdebug.h>

void handleSignal(int sig)
{
qDebug("handleSignal");
}

int main(int argc, char *argv[])
{
signal(SIGINT, handleSignal);

QCoreApplication a(argc, argv);

return a.exec();

}

it's worked signal via Ctrl + C without gdb.

but it's work failed with gdb and never enter my callback function "handleSignal".

[JonB]

@Tancen
So I gave you a bunch of suggestions and links in my previous post. These included sending the signal directly from gdb itself without using Ctrl+C, and other peoples' explanations about how to generate Ctrl+C signal when using gdb. What did you do about those suggestions?

[Tancen]

it's can't help me.
thank you

[Paul Colby]

Hi @Tancen,

handle SIGINT nostop pass works as you're expecting on Linux (using your code sample above), so this is likely Windows-specific. I don't currently have access to a Windows dev host, but I'd try not using qDebug.

My hunch (and its little more than that at this stage), is that your handler is being invoked (have you tried setting a breakpoint on it?) you're just not seeing any output. As you can see in the GDB output, you have more than one thread being started (there's only one on Linux, so presumably Qt or Win32 is doing something extra on Windows). You have no control over which thread will end up executing the handler - that's based on race conditions, and is exactly the sort of thing that will be affected by executing the application different ways (eg via a debugger, in this case). It is quite possible (though still just speculation), that qDebug 's output (or lack of) is related to the thread its being executed on.

So, I'd try replacing qDebug with a simple printf or std::cerr, and see if that shows anything.

Good luck.