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
Related
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
In lldb I'd like to break before C++ throws the exception, on when the actual signal is generated. I'd like to do this for any type of exception.
The following command will break on the C++ throw catcher
break set -E c++
I'd like to break on the cause of the exception and ignore the C++ throw/catch as if the application was crashing. I'd also like to do this for applications without source.
Is there any lldb voodoo I can use here?
I'm not entirely sure what you are asking.
Exceptions throws in C++ do two things, create the exception object, and then directly call some runtime routine (__cxa_throw on most Unixen) to implement the unwinding. The latter is the point where the exception breakpoint stops. There isn't any more preliminary than this that you could hook onto.
You could try breaking when the exception object is allocated. On OS X & Linux this is __cxa_allocate_exception, but I don't know if that will always get called or if there are alternate ways to make the exception... I don't see how you would gain much from that, however, it's just a couple of instructions later that you'll see the call to the throw method.
But maybe if you describe the problem you are actually trying to solve, we can answer more helpfully...
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.
I have a program failing with:
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
I imagine it's something to do with malloc/free, but I don't know which one.
What breakpoint can I in gdb set that will break on the error so that I can view a stack trace?
The program is a combination of C and C++, compiled with gcc 3.4.2.
It is not really malloc/free which causes the exception, it is "new" which is definitely in C++ part of your application. It looks like you are providing a parameter which is too big for "new" to allocate.
'std::bad_alloc' is caused by the following code for example:
int * p = new int[50000000];
What does backtrace says when you load crash dump into gdb?
If you cannot generate dump, you can ask GDB to stop when exception is thrown or caught.
Unfortunately, some versions of GDB support only the following syntax:
catch throw
which allows you to break application when any exception is thrown.
However, in help you see that it should be possible to run
catch throw std::bad_alloc
in newer versions.
And don't forget that:
(gdb) help catch
is a good source for other useful information.
It's quite possible that this happens due to some memory being overwritten, thus corrupting the memory allocation system's state (which is generally kept either before or after the memory blocks returned to the application).
If you have the possibility (i.e., you're on x86 Linux), run your program in Valgrind, it can often show you exactly where the corruption happens.
I have had this when trying to read in a file that doesn't exist... I'd try to create an internal buffer for the file contents, but because the file didn't exist, my creation of the buffer screwed up.
int lenth_bytes;
length_bytes = in_file.tellg();
new char [length_bytes]; // length_bytes hadn't been initialised!!!!
Remember kids, always initialise your variables :D and check for zero cases.
I'm using the d programing language to write a program, and I'm trying to use ddbg to debug it. When there is an exception, I want to have the program break whenever there is an exception thrown so that I can inspect the stack.
Alternatively, is there another debugger that works with d? Is there another way to get a stack trace when there is an exception?
You want to break when there's any exception thrown or just uncaught exceptions? Because I think the latter is already the default behavior.
You probably know this, but you get the stack trace by typing 'us' (unwind stack) at the prompt. Just trying to eliminate the obvious.
Anyway, I've never had to use onex. Never even heard of it. Another thing you could try is forcing execution to stop by putting in asserts.
You can get stack traces on exceptions by modding the runtime, by the way. The best resource is probably this backtrace hack page
Haven't used ddbg yet, but according to the documentation at http://ddbg.mainia.de/doc.html there is the
onex <cmd; cmd; ...> on exception execute list of commands
command.
I saw the onex command, but I couldn't find a break command. The two commands below don't seem to work.
onex break
onex b