I set a breakpoint in a destructor, which only gets called, when the program finishes completely. Now I start the program with CLion's debugger, but it never reaches the destructor. When I press on finish in CLion the debugger closes and the breakpoint never gets reached. How can I reach the breakpoint in the destructor in CLion?
You need to find a way to stop looping in your main thread, and jump to return 0; at the end of your int main(...) {. Alternatively, you can use exit(0), I believe. (Source: Difference between "return 0" and "exit (0)")
There's more:
You need to share your code, but there's this information, which you may find useful:
Please see these references:
Are Basic Object Destructors Called On Exit()?
Note that objects with automatic storage are not destroyed by calling exit (C++).
http://www.cplusplus.com/reference/cstdlib/exit/
The problem could be that, during exit, your destructor is never called, anyway. Hence, it is a leak but the OS will handle it.
Related
In GLFW documentation it is written that glfwTerminate will
This will destroy any remaining window, monitor and cursor objects, restore any modified gamma ramps, re-enable the screensaver if it had been disabled and free any other resources allocated by GLFW.
and that one should call it before terminating the program. From my understanding that means, that if this function is not called the operating system doesn't have to re-enable the screensaver or restore modified gamma ramps, which is bad. How do I ensure that it is called regardless of how the program ends?
It's possible to use std::atexit to ensure it is called at the end if the program is exited via the exit command or by returning from the main function. It is also possible to do that making an object with a destructor in the main function that terminates when it is destroyed. The problem is what to do when the program ends with a signal. It's not possible to just register a function using std::signal, because glfwTerminate calls standard library functions other than the ones listed in https://en.cppreference.com/w/cpp/utility/program/signal which the site says is undefined behavior.
How do I ensure the program calls glfwTerminate? Or is it just not possible? And do I understand it correctly that without it the program can leave a modified gamma ramp after getting a signal? And are there any other ways the program can stop without calling the function?
There is no guarantee that the program will call glfwTerminate in case of segfaults or other undefined errors, so it is better to handle all errors before you decide to close it. So, recommendation is calling before the program terminates to restore the modified gamma ramps and re-enable the screensave.
I'm interfacing a C program (main() is in C) with C++. At some points in my code I want to stop execution of the program. Now I'd like to know, how can I do this cleanly?
At the moment I call std::terminate() but more out of a lack of better ideas. The main thing that bugs me isn't even that I'm not freeing the memory (because it's freed anyway on program termination, right?) but that the MSVS Just-in-time Debugger pops up and I get an ugly error message about terminating the runtime in an unusual way.
EDIT: As this has caused confusion: Returning from main() with return 0 is not possible in this case.
If you concern about cleaning up and invoking destuctors then
exit(EXIT_SUCCESS); // or EXIT_FAILURE
is the best choice between exit, terminate and abort.
Function exit calls descructors and cleans up the automatic storage objects (The object which declared in the global scope). It also calls the functions passed to atexit.
Function abort is useful for abnormal exits and will not clean up anything. It doesn't call the functions passed to atexit.
Function terminate does not exist in C. It's useful when you have an exception and you can't handle it but finishing the program.
main function is where it starts, main function is where it should end usually. If you use return 0; it indicates succesful exit.
int main(void) {
//init
//do stuff
//deinit
return 0; // bye bye
}
You could also use exit(0);, but if your exit points are scattered all over the place it makes things harder to debug.
It's definitely possible to execute code before main is called, as seen by many examples in this question.
However, what if in that pre-main code, the program is told to exit via std::exit or std::abort? Since main is defined as the start of a program, what consequences are there from exiting before the start?
Upon printing something in each section, I get the following results:
Format:
Section: output
Main: main
Init (called before main): init
Exit (set up with std::atexit inside Init): exiting
Sample runs:
Init called without exiting:
init
main
returns 0
Init calls std::exit(0):
init
returns 0
Init calls std::abort:
init
crashes and returns 3 on Windows with GCC 4.7.2
crashes and brings up the usual box with VS11
returns 0 on LiveWorkSpace
Init sets handler and calls std::exit(0):
init
exiting
returns 0
Init sets handler and calls std::abort:
init
same deal as without the handler
While searching, I saw this question: Is there any way a C/C++ program can crash before main()?. However, it doesn't answer what I want to know: Is any of this behaviour, calling std::exit or std::abort before main, well-defined? Is any of this undefined behaviour?
The short answer is: there are (almost) no consequences. Some destructors may not be called if you unexpectedly call exit, but that's pretty much it.
Generally, not calling destructors is not the cleanest possible way, but then again the end result will be the same.
When a process terminates (via exit or abort or simply by segfaulting, or another reason), handles (kernel objects, files, etc.) are closed, and the memory associated with the program's address space is reclaimed by the operating system.
There is not much else to it either, because when you call exit or abort, you're basically requesting that the program terminates (these functions never return!) so you really can't expect anything to happen thereafter.
Note that registering a function like Init to be called before main is non-standard stuff, but you can get the same effect by having a constructor in a global.
So I realize that in fact I really do not need to do what I am about to explain but I am very picky about making sure my programs cleans up everything before exiting so I still want to do it...
I have a QApplication that I connect a single shot timer to the quit slot on. (in the future imagine this quit is really going to be generated from the UI on a user click so this is just for debugging) I have noticed that at first I was just allocating the qApp in the main function on the stack. The problem is in doing some research it seems the exec function does NOT HAVE to return. This means the main function stack does not get cleaned up. (Or well at least not until the program exits and the system reclaims that memory...) So in valgrind I have some QCoreApplication::init() memory "issues". Once again more just me being picky then really affecting things...
Anyways so I decided to malloc the QApplication and then try to free it just before the program closes. I can do this for signals but how about on the quit signal? I'm tied into the aboutToQuit signal but I feel like that's not the right stage to blow away the qApp. So my question is, IS there a right place to delete the qApp and if yes where?
The problem is in doing some research it seems the exec function does NOT HAVE to return.
Well, yeah, it doesn't "have" to return if your process is crashing and burning anyway, i.e. if you've called - directly or indirectly - std::terminate(), ::abort(), ::exit(), etc. Those library functions are used to quickly terminate the process and your problems aren't limited to the QApplication instance. Every object on the call stack, in every thread, will be leaked, and some of those objects you have neither access to nor any control of - the runtime and the libraries create them - and there's nothing you can do about it. The case of non-returning exec() is an exception, not the normal way your program should be ending. In terms of "what to do when exec() doesn't return: nothing. It's too late by then.
Hence - don't throw uncaught exceptions, don't ::exit() nor ::abort(), and don't worry about it. In every well-behaved Qt program, QCoreApplication::exec() returns.
Out of my curiosity..
I notice when I throw exceptions from constructor, if I compiled the code in debug mode and if I click on continue debugging (or continue stepping through), it won't exit the constructor until it reaches the end. Please note I don't have try{}catch{} wrapping the code that instantiate MyClass object.
I tried this in release mode, and can't really tell if it exits the constructor after the first throw or the last throw. Do you know if in release mode it leaves ctor since the first throw or the last? And why does it let me go to the next line when I'm in debug? shouldn't throw just exit the scope it's in?
MyClass::MyClass()
{
throw "exception1";
throw "exception2";
throw "exception3";
}
MyClass a;
I suspect that it's a debugging issue. An uncaught exception should, by default, kill the program. But your debugger stops the program at the line that caused the exception, instead. And the "continue debugging" button tells the debugger to just ignore the last fatal problem and continue going.
So the debugger continues on in the program until it reaches the second throw. Which would, again, be fatal. So the debugger stops there. Etc.
If there's a place that actually catches the thrown exception, you should see different behavior.