When debugging a C++ program with the GNU GDB debugger, I can step over the next line of code with the GDB command:
next
However, when an exception is thrown within that next line, like e.g.
throw SomeException();
then GDB continues to run until the next breakpoint instead of stopping within the first line of the catch block.
Is this a bug within GDB, or am I just using the wrong command?
I'm using GDB version 7.7 on MinGW32 / Windows.
On Linux this works properly. In particular there is a special debugging marker (either a function or an "SDT probe", depending on how things were built) in the low-level unwinding code that is used when an exception is thrown. GDB puts a breakpoint at this spot. When this breakpoint is hit, GDB examines the target stack frame of the throw and, if it is above the nexting frame, puts a temporary breakpoint at the target of the throw.
This required some changes in GDB, but also some changes in the C++ runtime in order to inform GDB about throws. As far as I know, nobody has ever done the work to port this code to MinGW. Maybe it could be done by modifying the appropriate unwind-mumble.c file in the GCC sources.
Related
I have a multi threaded program written in c++ running on ARM.
I have enabled global core dump of applications by running:
echo "/var/log/core.%e.%t" > /proc/sys/kernel/core_pattern
ulimit -c unlimited
An exception is thrown in the program which isn't being caught.
I open the core dump that was generated using eclipse.
I expect to see the code that throw the exception in the callstack.
But I can't see it.
The rest of the callstack for the other threads look ok
I tried to manually change the $SP of the first line in the callstack to the address defined in the verbose termiate line: 0xb6eba0d8 but that cause the callstack to only show the syscall line
How can I see more lines in this thread's stack?
There were two problems:
The stack was unwound. Until GCC 8 - When using std::thread, libstdc++'s function that calls the user's thread function contains a try/catch all statement. Using pthread instead solves this issue. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 for details
I was using libstdc++ without debug symbols while trying to debug. The function that was called by the thread was compiled with debug symbols but that wasn't enough. I used the file command to see that the library inside /usr/lib didn't have debug symbols, so I used the libraries from my Linaro distribution installation which did have.
I am using Codeblocks for the first time to run a cpp program. While compling the program an error occurs, I want to know the line number from the program where the error is evoking or in other words I want to see the stack trace of the program.
How can achieve this?
You can also use gdb. To debug, compile with g++ and -g at the end of the command and then run your program with gdb (in linux, gdb ./NameOfYourProgram). Then, you type r to run it, and when an error occurs, just type where and you get the stack. You can also set breakpoints and perform steps with gdb to examine the bug further.
Is there any gcc option I can set that will give me the line number of the segmentation fault?
I know I can:
Debug line by line
Put printfs in the code to narrow down.
Edits:
bt / where on gdb give No stack.
Helpful suggestion
I don't know of a gcc option, but you should be able to run the application with gdb and then when it crashes, type where to take a look at the stack when it exited, which should get you close.
$ gdb blah
(gdb) run
(gdb) where
Edit for completeness:
You should also make sure to build the application with debug flags on using the -g gcc option to include line numbers in the executable.
Another option is to use the bt (backtrace) command.
Here's a complete shell/gdb session
$ gcc -ggdb myproj.c
$ gdb a.out
gdb> run --some-option=foo --other-option=bar
(gdb will say your program hit a segfault)
gdb> bt
(gdb prints a stack trace)
gdb> q
[are you sure, your program is still running]? y
$ emacs myproj.c # heh, I know what the error is now...
Happy hacking :-)
You can get gcc to print you a stacktrace when your program gets a SEGV signal, similar to how Java and other friendlier languages handle null pointer exceptions. See my answer here for more details:
how to generate a stacktace when my C++ app crashes ( using gcc compiler )
The nice thing about this is you can just leave it in your code; you don't need to run things through gdb to get the nice debug output.
If you compile with -g and follow the instructions there, you can use a command-line tool like addr2line to get file/line information from the output.
Run it under valgrind.
you also need to build with debug flags on -g
You can also open the core dump with gdb (you need -g though).
If all the preceding suggestions to compile with debugging (-g) and run under a debugger (gdb, run, bt) are not working for you, then:
Elementary: Maybe you're not running under the debugger, you're just trying to analyze the postmortem core dump. (If you start a debug session, but don't run the program, or if it exits, then when you ask for a backtrace, gdb will say "No stack" -- because there's no running program at all. Don't forget to type "run".) If it segfaulted, don't forget to add the third argument (core) when you run gdb, otherwise you start in the same state, not attached to any particular process or memory image.
Difficult: If your program is/was really running but your gdb is saying "No stack" perhaps your stack pointer is badly smashed. In which case, you may be a buffer overflow problem somewhere, severe enough to mash your runtime state entirely. GCC 4.1 supports the ProPolice "Stack Smashing Protector" that is enabled with -fstack-protector-all. It can be added to GCC 3.x with a patch.
There is no method for GCC to provide this information, you'll have to rely on an external program like GDB.
GDB can give you the line where a crash occurred with the "bt" (short for "backtrace") command after the program has seg faulted. This will give you not only the line of the crash, but the whole stack of the program (so you can see what called the function where the crash happened).
The No stack problem seems to happen when the program exit successfully.
For the record, I had this problem because I had forgotten a return in my code, which made my program exit with failure code.
I have a Fortran program compiled with gfortran with the -fcheck=bounds compiler option. This causes the code to report "array out of bounds" errors and subsequently exit.
I would like to debug my program using gdb to find the cause of the error. Unfortunately in gdb the code will still just exit on an out of bounds error.
Is there a way to tell gdb to stop execution when an out of bounds error occurs?
Compile with -g to get debugging information. Then, first, I placed a break point on exit, this works fine, once the program stops you'll be able to backtrace from exit to the point of the error.
The backtrace also passes through a function called _gfortran_runtime_error_at, so you might have more luck placing the breakpoint there, this worked for me, and obviously will only trigger when you get a run time error.
To set a breakpoint on gdb, use the command break then the name of the file you are debugging, a colon and the number of the line from which you want to break execution :
break main.f90:24
will stop the execution at line 24 of program main. Then you can use the step command to jump to the next line and so on. At this point you can use print to check the value of any variable you want. If you have defined another breakpoint, you can use the command next to jump to the next breakpoint directly.
You will need to compile your program with the -g flag to be able tu use gdb
While debugging a program in GDB, I get an unexpected "program exited normally". So I'm wondering if is there a way to find out from where (which line) the program exited.
Program is multi-threaded, if that matters.
You could try the GDB command break exit to set a breakpoint on the exit(2) library call. If that doesn't get you what you need, maybe break _exit. You might need to start your program with 'sta' before getting the latter breakpoint to take. In either case, you should then be able to use the where command to get a stack trace showing where you were when the program decided to exit.
Usually with the command below when the application has finished executing:
(gdb) thread apply all bt
Of course, if you want to know the exact line you must compile your application with debugging symbols, i.e. -g
Set a breakpoint on _exit and then examine the stack.