I can tell the gdb debugger to stop as soon as any C++ exception is thrown by setting a catchpoint with the gdb command
catch throw
However, is there any way to only stop at uncaught C++ exceptions (like in C# or Java)? This would make it much easier to find bugs in some situations.
Thanks!
If an exception is uncaught, the special library function terminate() is automatically called. Terminate is actually a pointer to a function and default value is the Standard C library function abort(). You may be able to set a breakpoint on the call to the abort() function and identify the location of the uncaught exception from there.
break abort
...
run
...
bt
You can install your own terminate() function by using std::set_terminate(). You should be able to set a breakpoint on your terminate function in gdb. You may be able to generate a stack backtrace from your terminate() function and this backtrace may help in identifying the location of the exception. Additional details are provided here.
Related
I have a non-void function which returns a value to be used as an input of a class constructor, but there is a possibility for that value not to be available, so I want to return the value in case of success or just terminate (std::terminate()) the application in case of failure before the function return.
Since std::terminate is called by the runtime according to https://en.cppreference.com/w/cpp/error/terminate, am I obliged to throw an exception and let the runtime decide whether the program is terminated or not?
What about the following warning I read in a simple test I just performed? "terminate called without an active exception"
Am I going in a stupid way?
Thanks for your insights in advance!
... I obliged to throw an exception and let the runtime decide whether the program is terminated or not?
It is up to you. If you want to be able for an exception to be caught somewhere up the call stack then you should throw an exception. In cases you want to terminate because there is no way to recover then calling std::terminate is fine. Just consider that if you throw an exception which is not caught then the program terminates anyhow, so you can choose to either catch it or not, while std::terminate terminates always.
The same page that you linked to, in your question, also has the following statement:
std::terminate() may also be called directly from the program.
I have a crash in a multi threaded application and for whatever reason I can't manage to catch the exception before the stack is partially unwound.
So now I am trying to catch it by connected with gdb and using catch throw. However, I am getting lots of other unrelated and caught exceptions. How can I ignore those?
I tried ignore 1 1000000, but this doesn't ignore just the exception currently focused, but ignores all catch throw exceptions.
Any ideas how I can ignore that particular one only? e.g. maybe by file and line number?
Since version 7.9, gdb has included some convenience functions like $_caller_is and $_any_caller_is. These can be used as conditions on a breakpoint to make it stop only when a certain call stack is seen.
So, for example, if you know the spot at which the exception is thrown, you could do something like:
(gdb) catch throw if $_any_caller_is("functionname")
However, if you know the throwing function, it seems to me that it would be simpler to just set a breakpoint at that particular throw.
Another option in some situations is to filter the exception by type. This functionality is built into catch throw since version 7.7. This form accepts a regular expression matching the type name:
(gdb) catch throw NameOfType
I have a weird situation. My game is definitely being built with debugging information, and I can merrily hit breakpoints and step through code, and look at data. No settings are unusual. I have ruled out multithreading as a problem.
When I have an actual bug, and a legitimate crash, i get no call stack. A typical crash bug will be
First-chance exception at 0x004678da in Democracy3Debug.exe: 0xC0000005: Access violation reading location 0x0000004c.
Unhandled exception at 0x774015de in Democracy3Debug.exe: 0xC0000005: Access violation reading location 0x0000004c.
And the callstack is just ntdll and some disassembly. I must have changed some option somewhere, but cannot imagine what. Any ideas?
Those errors are indicative of hardware exceptions due to an attempt on your part to access memory that your process cannot read or write. In particular, it looks like you are directly or indirectly attempting to access some element 76 bytes from the address referred to by some pointer, but that pointer is in fact null (thus the access violation reading location 0x0000004c).
Your debug information may not be invalid in any way, you simply may legitimately be in some code inside nt.dll -- for example, if you passed a null pointer to a Windows API function that does not permit them. If you don't have symbols loaded for nt.dll, you won't get a useful call stack.
It's also possible the access violation's coming from a bad pointer you passed that wasn't used until some callback was invoked by the Windows API, which might explain why you don't see your code anywhere in the stack frame.
Enabling break-on-throw in the VS IDE (Debug -> Exceptions, check the boxes for relevant exception types) can help you break earlier when this occurs, but may not help diagnosing the problem if it's legitimately not directly from your code.
You can also use structured exception handling to integrate these exceptions and C++'s exceptions for catching purposes. You may also want to look in to using a symbol server to get the symbols for the Windows DLLs.
Your exception isn't being caught, so it's moving up the call stack all the way to main and terminating your app.
MSDN:
If a matching handler (or ellipsis catch handler) cannot be found for
the current exception, the predefined terminate run-time function is
called.
There's usually an option to allow you to pause debugging when an exception is thrown.
How to: Break When an Exception is Thrown (Visual Studio 2012)
You could also have a catch statement at top level and examine the exception (.what() often gives an description) when you catch it.
Update: You most likely can't catch this exception because it's an Access violation (not a C++ exception, but the pause should still work afaik). If you're on Windows you could use SEH to catch it.
What's the difference between those three, and how shall I end program in case of exception which I can't handle properly?
abort indicates "abnormal" end to the program, and raises the the POSIX signal SIGABRT, which means that any handler that you have registered for that signal will be invoked, although the program will still terminate afterwords in either case. Usually you would use abort in a C program to exit from an unexpected error case where the error is likely to be a bug in the program, rather than something like bad input or a network failure. For example, you might abort if a data structure was found to have a NULL pointer in it when that should logically never happen.
exit indicates a "normal" end to the program, although this may still indicate a failure (but not a bug). In other words, you might exit with an error code if the user gave input that could not be parsed, or a file could not be read. An exit code of 0 indicates success. exit also optionally calls handlers before it ends the program. These are registered with the atexit and on_exit functions.
std::terminate is what is automatically called in a C++ program when there is an unhandled exception. This is essentially the C++ equivalent to abort, assuming that you are reporting all your exceptional errors by means of throwing exceptions. This calls a handler that is set by the std::set_terminate function, which by default simply calls abort.
In C++, you usually want to avoid calling abort or exit on error, since you're better off throwing an exception and letting code further up the call stack decide whether or not ending the program is appropriate. Whether or not you use exit for success is a matter of circumstance - whether or not it makes sense to end the program somewhere other than the return statement in main.
std::terminate should be considered a last-ditch error reporting tool, even in C++. The problem with std::terminate is that the terminate handler does not have access to the exception that went unhandled, so there's no way to tell what it was. You're usually much better off wrapping the entirety of main in a try { } catch (std::exception& ex) { } block. At least then you can report more information about exceptions that derived from std::exception (although of course exceptions that do not derive from std::exception would still end up unhandled).
Wrapping the body of main in try { } catch(...) { } isn't much better than setting a terminate handler, because again you have no access to the exception in question. There is at least one benefit, though: whether stack unwinding is done when an exception goes completely uncaught is implementation defined, so if you need guaranteed stack unwinding, this would be a way to get that.
std::abort and std::exit (and more: std::_Exit, std::quick_exit) are just lower level functions. You use them to tell the program what you want it to do exactly: what destructors (and if) to call, what other clean-up functions to call, what value to return, etc.
std::terminate is a higher level abstraction: it is called (by either run-time or you) to indicate that an error in the program occurred and that for some reason it is not possible to handle by throwing an exception. The necessity for that typically occurs when error occurs in the exception mechanism itself, but you can use it any time when you do not want your program to continue beyond the given error. I compiled the full list of situations when std::terminate is called in my post. It is not specified what std::terminate does, because you are in control of it. You can configure the behavior by registering any functions. The limitations you have are that the function cannot return back to the error site and it cannot exit via an exception, but technically you can even start your message pump inside. For the list of useful things that you can do inside, see my other post.
In particular, note that std::terminate is considered an exception handler in contexts where std::terminate is called due to a thrown exception that could not be handled, and you can check what the exception was and inspect it by using C++11 using std::rethrow_exception and std::current_exception. It is all in my post.
quick_exit() !
If your program is multi-threaded, then calling exit() will most likely result in a crash because global/static std::thread objects will be attempted to destruct without exiting their threads.
If you want to return an error code and exit the program (more or less) normally, call quick_exit() in multi-threaded programs.
For abnormal termination (without a possibility for you to specify the error code), abort() or std::terminate() can be called.
Note: quick_exit() has not been supported by MSVC++ until version 2015 .
terminate() is automatically called
when an exception occurs that cannot
be handled. By default, terminate()
calls abort(). You can set a custom
handle with set_terminate() function.
abort() sends the SIGABRT signal.
exit() is not necessarily a bad
thing. It successfully exits the
application, and calls atexit()
functions in LIFO order. I don't
normally see this in C++
applications, however, I do see it in
many unix based applications where it
sends an exit code at the end.
Usually a exit(0) indicates a
successful run of the application.
terminate leaves you the possibility to register what will happen when it is called. Should be one of the other two.
exit is a normal exit allowing to specify an exit status. Handlers registered by at_exit() are run
abort is an abnormal exit. The only thing which is ran is the signal handler for SIGABRT.
My advice would be not to use any of them. Instead, catch the exceptions you can't handle in main() and simply return from there. This means that you are guaranteed that stack unwinding happens correctly and all destructors are called. In other words:
int main() {
try {
// your stuff
}
catch( ... ) {
return 1; // or whatever
}
}
I am programming in C++ on Linux platform.
My program terminates with this (unhandled???) exception:
"terminate called after throwing an instance of 'long'"
Aborted
The code that is throwing the exception is inside try-catch block, then why should this happen??
The exception is thrown while returning from a function.
I am used to C programming and have very little experience in C++ (which is the main problem). I don't know how to debug this issue. I don't expect a solution but a direction/pointer for debugging this problem.
Thanks in advance.
You can run your application under gdb (having built it with debug info using -g) and get it to break when an exception is thrown using the command:
(gdb) catch throw
This will take you to the origin of the exception. Some more info is available in this question:
Run an application in GDB until an exception occurs
Note that it is somewhat unusual to throw an ordinal type (such as a long). It may be in some temporary code, so grepping around might find it quickly enough.
It there anywhere on the call-stack with a exception specification or here? If there is then you might have this problem - you probably want to remove all of them.
If you are using gcc, then you can add this code first thing in main():
#ifdef __GNUC__
std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
#endif // ifdef __GNUC__
(More details at http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt02ch06s02.html)
Which will give you a better traceback from such exceptions.
you are probably catching the wrong exception type
use
catch(long)
or
catch(...)
Normally, I would recommend to set a breakpoint in the constructor of the thrown type -- but in this case ... I must admit to never have experienced that somebody has thrown a long like
throw 42;
That seems to me strange. Some debuggers might be able to catch an exception when it is thrown.
Is the called function yours?
Use set_terminate to break GDB
Example for set_terminate() is here
When it trigged - use bt command in GDB to see backtrace