How can I perform line by line crash debugging to deal with "has stopped working" error in c?

Question

I have a c project compiled with GCC.When I run my test.exe program ends with "test.exe has stopped working" but compiled successfully.How can I debug my program and how can find where is my mistake?

Technique 1: I tried to printf("Successful 1..."),printf("Successful 2...") on the beginning of every single line of code but this method is frustrating.Are there tools(gdb...) to debug my code line by line for me?

printf("Successful 1...")
//code
printf("Successful 2...")
//code

How can I debug my program line by line with GDB? Can I go to the error line directly with GDB?

Edit 1: I use gdb and type run command and get following output which is not helpful(segmentation fault but where?):

Starting program: C:\Users\q\..././bin/test.exe
[New Thread 3292.0x22b8]
[New Thread 3292.0x1fb8]
Program received signal SIGSEGV, Segmentation fault.
0x7696e3e3 in ungetwc () from C:\WINDOWS\SysWOW64\msvcrt.dll

Edit 2: How to debug using gdb? doesn't contain helpful answer to my question.Not possible duplicate of my answer

Edit 3:(bt method output) I have program that contain 6 source and 6 header files.And every header and source files contain three and more than function pointers that perform some action.I tried debug with gdb bt and get following output:

#1  0x00000001 in ?? ()
#2  0x00000073 in ?? ()
#3  0x00000032 in ?? ()
#4  0x00000000 in ?? ()

My makefile:

    all: compile run
    compile :
        gcc -I ./include/ -o ./lib/... .o -c ./src/... .c
        gcc -I ./include/ -o ./lib/... .o -c ./src/... .c
        gcc -I ./include/ -o ./lib/... .o -c ./src/... .c
        gcc -I ./include/ -o ./lib/... .o -c ./src/... .c
        gcc -I ./include/ -o ./lib/... .o -c ./src/... .c
        gcc -I ./include/ -o ./bin/test ./lib/... .o ./lib/... .o ./lib/... .o ./lib/... .o ./lib/... .o  ./src/test.c

    run:
        gdb ./bin/test.exe

https://ericlippert.com/2014/03/05/how-to-debug-small-programs/ https://stackoverflow.com/questions/2069367/how-to-debug-using-gdb and just because it is a great article: https://ericlippert.com/2014/03/21/find-a-simpler-problem/ — Yunnosch, Apr 20 '18 at 21:48
simply run it with gdb and gdb will show you where it crashes — Jabberwocky, Apr 20 '18 at 21:48
Possible duplicate of [How to debug using gdb?](https://stackoverflow.com/questions/2069367/how-to-debug-using-gdb) — Yunnosch, Apr 20 '18 at 21:50
Also remember to enable lots of warning when building. The compiler may detect the problem but not show it to you with the default warning level. Add at least `-Wall -Wextra -pedantic` when building. — Some programmer dude, Apr 20 '18 at 21:50
The accepted answer in the question you and @Yunnosch link to contains one very good command: `bt`. If you use that you will get a list of the function call stack, which you can use the `up` command to go up until you're at your code. Then you use `print` to print values of all involved variables. Of course, make sure you're building with debug information, by adding the `-g` flag. — Some programmer dude, Apr 20 '18 at 21:59
That looks like stack corruption. Time to create a [Minimal, Complete, and Verifiable Example](http://stackoverflow.com/help/mcve) and show us. Something you should have done from the start! — Some programmer dude, Apr 20 '18 at 22:06
Note that when you get a segmentation fault, the root cause may be something that happened much earlier in the program. It corrupts memory and leaves a timebomb that goes off later when something else tries to use that memory. — Barmar, Apr 20 '18 at 22:27
`valgrind` is can often be helpful in diagnosing these types of memory use errors. — Barmar, Apr 20 '18 at 22:27

score 1 · Answer 1 · answered Apr 20 '18 at 22:12

You are getting segmentation fault and that is why your application is not running. Segmentation fault is a run time problem, even if your program compiles successfully.

In gdb after you get this:

Program received signal SIGSEGV, Segmentation fault.

type bt. The gdb's bt command will show you the back trace of your running program. It tells you which flow your program took and also the exact line which caused the segmentation fault and made your application crash.

The output of bt will be more 'readable' if you have built your application in debug mode. If you are using using gcc, you need to add -g flag to build in debug mode

Steve Summit · Accepted Answer · 2018-04-20T22:36:55.233

Sometimes, if your bug is particularly bad, it overwrites the stack and demolishes all the clues that gdb (and particularly the bt command) would need in order to show you where you were.

In that case you can try something like this:

Start gdb, set a breakpoint on main, run your program, wait for the breakpoint to be hit.
Single-step through your program with the n command, which steps over, not down into, functions. (That is, each called function runs all at once; you're not single-stepping recursively down into each function.) Sooner or later one of your single-steps will step over a function which crashes. Now you've narrowed it down a bit.
Set a breakpoint on that function.
Rerun the program.
When you hit the breakpoint inside the troublesome function, again begin single-stepping. Sooner or later one of your single-steps will enter a sub-function which crashes. Now you've narrowed it down a bit more.
Continue in this fashion until you've located the actual line causing the crash.

How can I perform line by line crash debugging to deal with "has stopped working" error in c?

2 Answers2