I am using SDL for an OpenGL application, running on Linux. My problem is that SDL is catching SIGINT and ignoring it. This is a pain because I am developing through a screen session, and I can't kill the running program with CTRL-C (the program the computer is running on is connected to a projector and has no input devices).
Is there a flag or something I can pass to SDL so that it does not capture SIGINT? I really just want the program to stop when it receives the signal (ie when I press ctrl-c).
Ctrl-C at the console generates an SDL_QUIT event. You can watch for this event using SDL_PollEvent or SDL_WaitEvent, and exit (cleanly) when it is detected.
Note that other actions can generate an SDL_QUIT event (e.g. attempting to close your main window via the window manager).
I have found an answer:
The SDL_INIT_NOPARACHUTE flag will capture fatal signals so that SDL can clean up after itself. It works for things like SIGSEGV, but apparently SIGINT is not fatal enough.
My solution is to reset the signal handler to SIGINT after SDL has been initialised:
SDL_Init(SDL_INIT_VIDEO | SDL_INIT_NOPARACHUTE);
signal(SIGINT, SIG_DFL);
Thanks Cache for you input, it put me on the right track.
Michael
In SDL_quit.c, there's a check for hints to determine whether the signal handlers should not be used in SDL_QuitInit(). Not sure if this existed in older versions when the original question was asked, but may be handy for those coming here fresh.
Just tested on my Windows application, I can now receive all signals properly again, using:
SDL_SetHint(SDL_HINT_NO_SIGNAL_HANDLERS, "1");
SDL_Init(...);
Passing the SDL_INIT_NOPARACHUTE initialisation flag to SDL_Init "Prevents SDL from catching fatal signals".
See: http://www.libsdl.org/cgi/docwiki.cgi/SDL_Init
If you're not actually using an event loop for some reason, you can use SDL_QuitRequested in your "poll stuff" loop.
Related
I am working on a TCP server that I'm developing on CLion under Windows 10.
I would like my program to be able to end properly, when I click on "stop" my program. I thought CLion was sending a signal, but after trying to catch them all, it looks like it does not.
So my question is, how does CLion stop running the program? Is it possible to detect it within the program?
Thank you in advance.
I found my answer here.
According to this link, signals are actually used :
Click this button to terminate the current process externally by means
of the standard shutdown script. Clicking the button once invokes soft
kill allowing the application to catch the SIGINT event and perform
graceful termination (on Windows, the Ctrl+C event is emulated). After
the button is clicked once, it is replaced with icon run tool window
kill indicating that subsequent click will lead to force termination
of the application, e.g. on Unix SIGKILL is sent.
I have a C++ application that suddenly stops working when I do a certain action (clicking at a button in gtk). I tried debugging it, creating Signal Handlers for SIGTERM, SIGABORT, SIGILL, etc to write a backtrace with the gcc functions, tried to attach a debugger, etc. Nothing. I just do not get any output from anything, the program just vanishes from the memory.
Are there any techniques I have not tried yet? I dont know how to debug this problem.
I forgot to mention: This happens on a Linux system (tried debian and ubuntu). Both with X11 (not wayland)
It could be:
A signal. By default, gdb stops on error signals, so no custom handler is needed.
exit() function and any other function from exit family (like _exit, _Exit , etc.). Use b exit to set a breakpoint.
Since it's c++, and exception could be thrown. Use catch throw to stop when an exception is thrown.
The last thread exit. b pthread_exit.
Thread cancellation. b pthread_cancel.
main function normally reached its end. Use disassembly to set a breakpoint on address.
If all of this doesn't help, attach to your application before the button is pressed, pause it with Ctrl+c in gdb. Then, press the button (while the window is unresponsive). A gtk application should normally dispatch the event from X11 queue even if it was paused. Do step by step assembly debugging with ni and si.
I have just got this problem for a few days. Before, I've always thought that letting the program exit by returning from main and clicking close the console window is the same way to end the program.
However, I've found that they are different. Since my program opens a camera which is an object. And closing the console windows does not destroy or clean up the object. So the next time I have error to open the camera again
I just need a confirm if this is true?
Then why only until now I can see the problem?
Closing a console window in Windows, kills the running program (or stack of running programs). Unless it has registered a handler for this event, it gets no chance to clean up. If you want solution, register a handler.
Hm, consulting the documentation, wait a few secs…
OK, look up SetConsoleCtrlHandler.
Closing a running console application will kill the process, not giving you the chance for any clean up code. I guess you could hook a windows message loop to trap the WM_CLOSE message and do proper cleanup, but at the end of the day, you just shouldn't kill the process.
I am porting a Linux app to Windows written in Qt. The application needs to save some settings before closing. On Linux, we can do that by signal handlers for SIGTERM etc. How can I implement the same on Windows.
If you are using the Qt event loop, you can catch the following signal:
void QCoreApplication::aboutToQuit() [signal]
This signal is emitted when the application is about to quit the main event loop, e.g. when the event loop level drops to zero. This may happen either after a call to quit() from inside the application or when the users shuts down the entire desktop session.
The signal is particularly useful if your application has to do some last-second cleanup. Note that no user interaction is possible in this state.
Other than that, you may be looking for the following messages below if the aforementioned signal is not appropriate for your use case:
WM_QUIT: http://msdn.microsoft.com/en-us/library/windows/desktop/ms632641(v=vs.85).aspx
WM_CLOSE: http://msdn.microsoft.com/en-us/library/windows/desktop/ms632617(v=vs.85).aspx
WM_QUERYENDSESSION: http://msdn.microsoft.com/en-US/library/windows/desktop/aa376890.aspx
WM_ENDSESSION: http://msdn.microsoft.com/en-US/library/windows/desktop/aa376889.aspx
I think the other answers completely miss the point: When you forcibly end an application, it's like SIGKILL on Unix. There's no way to handle it - except ahead of time. What I mean by handling it ahead of time is making sure that you save the settings every time they are changed. Of course you can optimize this behavior, for example save the settings every few seconds if they are dirty, if you want to minimize the number of disk accesses (think power consumption on mobile devices).
A lot of this is handled by QSettings for you. As long as you use QSettings, you'll get reasonable behavior. If you're saving files yourself, use QSaveFile as it deals with flushing the file and approximating atomic file replacement, so that you won't lose the settings if the kill (forced termination) comes in the middle of you doing the writing.
The aboutToQuit signal emitted by QCoreApplication is what you want to react to if you want to simply do something when the application being asked to quit. This is equivalent to handling the WM_QUIT message, or dealing with SIGTERM on Unix. So doing it in platform-specific way is pointless as Qt does it for you already. There's equally no point in handling WM_CLOSE since that's a message that only windows get, and again Qt already handles it for you.
You can also participate in the logoff/shutdown process by installing a QAbstractNativeEventFilter and processing the WM_ENDSESSION and WM_QUERYENDSESSION. This only makes sense if you want to know ahead of time that the application will be quit. Unless you explicitly want to stop the shutdown/logoff, you don't need to worry about it.
I think it might be better to handle the QApplication::commitDataRequest signal (or QGuiApplication::commitDataRequest in Qt5) instead of aboutToQuit. Just connect the signal to your function for saving settings.
Here are some related discussions: http://qt-project.org/forums/viewthread/33329
session logoff will emit aboutToQuit
case WM_ENDSESSION: {
sm_smActive = false;
sm_blockUserInput = false;
bool endsession = (bool) wParam;
// we receive the message for each toplevel window included internal hidden ones,
// but the aboutToQuit signal should be emitted only once.
QApplicationPrivate *qAppPriv = QApplicationPrivate::instance();
if (endsession && !qAppPriv->aboutToQuitEmitted) {
qAppPriv->aboutToQuitEmitted = true;
int index = QApplication::staticMetaObject.indexOfSignal("aboutToQuit()");
qApp->qt_metacall(QMetaObject::InvokeMetaMethod, index,0);
// since the process will be killed immediately quit() has no real effect
QApplication::quit();
}
RETURN(0);
}
I do not know Qt. If you can afford to be Windows only WM_QUERYENDSESSION and WM_ENDSESSION messages might be the right thing to do.
I guess the question says it all, but, what happens if someone closes a c++ console app? As in, clicks the "x" in the top corner. Does it instantly close? Does it throw some sort of exception? Is it undefined behavior?
Closing a c++ console app with the "x" in the top corner throws an CTRL_CLOSE_EVENT which you could catch and process if you set a control handler using the SetConsoleCtrlHandler function. In there you could override the close functionality and perform whatever you wished to do, and then optionally still perform the default behavior.
I imagine that the console process just gets unceremoniously killed by the OS. If you want to trap this event and do something it looks like the SetConsoleCtrlHandler function is the way to do it.
See also:
How to handle a ctrl-break signal in a command line interface
Console Event Handling
On Linux and other Unix systems, the console runs as a separate process. As you close the shell, it sends the SIGHUP signal to the currently active process or processes that are not executed in the background. If the programmer does not handle it, the process simply terminates. The same signal is sent if you close the SSH session with a terminal and an active process.
SIGBREAK is raised on Windows.