I am using vim for c++ programming. I have bound the compile command to ctrl+c in vim and I run it in another tmux pane by running ./main.out. My problem is that when my c++ program gives me segmentation fault error, I don't know which line has caused the problem. But when I compiled and ran the program in vscode, it showed me the line that caused the error.
I'm seeking for a way to find out the lines that cause runtime errors like segmentation fault error while running the program's binary file in console.
This is an example output when I do ./main.out:
[1] 24656 segmentation fault (core dumped) ./main.out
When compiling the program, add the -g compiler flag, or even better -ggdb3, which will give you a much prettier output, by adding debugging symbols to the executable. Also, make sure that you compile with the -O0 optimization level.
To actually debug the program, run gdb ./main.out to start the program in a debugging session. If you then run r, gdb will start executing the program, and then stop at the line that gives the segfault.
To figure out how you got to that point, run bt while in the debugging session, and you will get a backtrace, which will show you all the function calls that were made to get to the line of code that crashed.
You can of course do a lot more than this (and you will probably need to, since locating the source of an error is often only the first step). You can use p to print the values of variables, set watchpoints, and many more things. For a while now, gdb even ships with a full fledged python interpreter, so you can even write a python script for your custom debugging needs.
Learning how to use gdb can seem overwhelming at the start, but persevere, and I guarantee the effort will pay off big time :)
Ditto on Adin
Also your code can crash due to a call in which the parameter/s are acceptable but cause the proverbial out of range protection fault from some library somewhere if you don't have those debug versions. If an assembly routine is used inside there, they can do some strange things.
So don't be afraid to add temporary code to help like finding a single call that crashes when 1,000,000 other calls to the same did not.
Is why I like to use a lot of generated randoms if possible to test when you got it fixed.
Related
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 am using QtCreator 3.6.1 on Ubuntu 14.04 with gcc as my main compiler.
My Qt project is being built in debug mode. However, whenever I press F5, to try to step into the code by setting break points, my code crashes (since the code is buggy) but instead of stopping at the breakpoint, it shows me assembly output!
Here is a screen shot. The code seems to have crashed at where you see the yellow arrow, but I just don't know where in the source code it is!!!
In fact, I have set my breakpoint at a cout statement as you can see here.
Not even the cout statement is executing. The code seems to be crashing before main is executed. I don't know if this is QtCReator problem or something else. I have added -O0 and -g option
to the QMAKE_CXXFLAGS option just to be sure, that debugging symbols are being added, yet I get this problem.
EDIT:
My stack trace looks like this
Also I am not sure if this helps, but when I run the program through the terminal with LD_DEBUG in front of the program's name, I get a huge amount of output.
The last three lines are
.
.
.
7934: symbol=_ZN11QMetaObject8addGuardEPP7QObject; lookup in file=/usr/lib/x86_64-linux-gnu/libQtGui.so.4 [0]
7934: symbol=_ZN11QMetaObject8addGuardEPP7QObject; lookup in file=/usr/lib/x86_64-linux-gnu/libQtCore.so.4 [0]
7934: binding file /usr/lib/x86_64-linux-gnu/libQtGui.so.4 [0] to /usr/lib/x86_64-linux-gnu/libQtCore.so.4 [0]: normal symbol `_ZN11QMetaObject8addGuardEPP7QObject'
[1] 7934 segmentation fault (core dumped) LD_DEBUG=all ./CGALQT_Fix_MainWindow
for this, your application has to link to debug libraries. To investigate where your app crashes, you don't usually need this because you can see all of your own methods in function stack.
I'm using Ubuntu and gcc. My application crashes I only have Segmentation fault message in console. (previously Segmentation fault (core dumped) was reported but now it changed to just Segmentation fault).
There are no hints where the problem is so I do not understand how should I fix the problem. I need some hints to find what caused this - ideally complete stack trace or at least object type/method or something like this.
What would be the correct way of troubleshooting such type of problem? (may be compile with some extra flags, run some tools, collect core dump and analyze it somehow?)
You might well need to enable core dumps with
ulimit -c unlimited
Once you have a core dump, you can look at the program state with GDB:
gdb my_prog core
You should then have the same view that you would have had if you'd run the program under GDB until it crashed - you could just do that, rather than collecting the core dump. In particular, it will show you which line caused the segfault, and the state of the call stack at that point.
To get the best debugging view, you should tell the compiler to include debugging symbols (-g) and disable optimisation (-O0).
you can use the gdb tools to help debuging.
run gdb ./your_app_name on terminal if you have the gdb installed and you will see some infomation as follow:
.....
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./gsvod_client...done.
(gdb)
then input "r" to start your app, if it crashed again, you can type 'bt' to see the line where the problem occured.
I have a large C++ function which uses OpenCV library and running on Windows with cygwin g++ compiler. At the end it gives Aborted(core dumped) but the function runs completely before that. I have also tried to put the print statement in the end of the function. That also gets printed. So I think there is no logical bug in code which will generate the fault.
Please explain.
I am also using assert statements.But the aborted error is not due to assert statement. It does not say that assertion failed. It comes at end only without any message.
Also the file is a part of a large project so I cannot post the code also.
gdb results:
Program received signal SIGABRT, Aborted.
0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
It looks like a memory fault (write to freed memory, double-free, stack overflow,...). When the code can be compiled and run under Linux you can use valgrind to see if there are memory issues. Also you can try to disable parts of the application until the problem disappears, to get a clue where the error happens. But this method can also give false positives, since memory related bugs can cause modules to fail which are not the cause of the error. Also you can run the program in gdb. But also here the position the debugger points to may not be the position where the error happened.
You don't give us much to go on. However, this looks like you are running into some problem when freeing resources. Maybe a heap corruption. Have you tried running it under gdb and then looking where it crashes? Also, check if all your new/delete calls match.
Load the core dump together with the binary into gdb to get an idea at which location the problem list. Command line is:
gdb <path to the binary> <path to the core file>
For more details on gdb see GDB: The GNU Project Debugger.
Run it through AppVerifier and cdb.
E.g.
cdb -xd sov -xd av -xd ch <program> <args>