5

I have been asked in an interview how can you debug segmentation fault in C program using GDB.

I told them we can compile our program with -g option so as it add debugging information to binary file and can read core dump file but then interviewer told me if he we have 3 to 4 files compiled together but one of them causing segmentation fault then how do we debug in GDB?

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
Amit Singh Tomar
  • 8,380
  • 27
  • 120
  • 199
  • Unless I'm really misunderstanding what you're asking, you'd still compile them all with -g and debug in the exact same way. – Joachim Isaksson Jan 23 '12 at 09:51
  • I also gave them the same solution but they didn't impress at all ,what they arguing like it won't tell us the exact file name causing the segmentation fault – Amit Singh Tomar Jan 23 '12 at 09:56
  • 1
    Actually, of all the interview questions I've seen around here, this one is actually pretty sensible. Makes sense to check whether a developer knows how to use whatever debugger is available on the respective platform. – Frerich Raabe Jan 23 '12 at 10:01

6 Answers6

3
$ gcc -ggdb s1.c s2.c s3.c -o myprog
$ gdb myprog
(gdb) run --arg1 --arg2

GDB will run the program as normal, when the segmentation fault occurs GDB will drop back to its prompt and it will be almost the same as running GDB with a core file. The major difference is there are some things you cannot do/print with a core file that you can when the program has crashed inside of GDB. (You can use print to call some functions inside the program, for example.)

You can also attach to an already running program using gdb --pid <the programs pid>.

Either with a core file or with one of the methods above, when you have the GDB prompt after the crash, type backtrace (or bt for short) and GDB will show you the stack at the time of the crash, including the file names and line numbers of each call and the currently executing line.

SoapBox
  • 20,457
  • 3
  • 51
  • 87
  • I thought we should use "gcc -g " , what is meaning of "gcc -ggdb" – pankaj kushwaha Oct 16 '15 at 06:45
  • [The manual](https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Debugging-Options.html#Debugging-Options) explains... -ggdb can produce extra information for GDB that -g doesn't. If you're going to use GDB, you shoudl use -ggdb. – SoapBox Oct 18 '15 at 00:22
1

compile the code in normal way by giving gcc filename you will get a .out file, start running that and get the process id by giving ps -aef | grep filename.out

in a another window type gdb and enter,inside gdb prompt give attach processid (processid you will get from above command),give c to continue.once the execution finishes give "bt" inside gdb.you will get the place where the segmentation is occurring.

Lukasz Koziara
  • 4,274
  • 5
  • 32
  • 43
Ramanaidu
  • 11
  • 1
1

If you are working under Linux the easier way to find segmentation fault is by using the tool named VALGRIND: http://valgrind.org/ .

You just need to compile your code with -g flag and then run ./valgrind .

Then you will know exactly in which function and in which line of code there is an error-uninitialized memory/memory read out of allocated space or sth.

Wookie88
  • 33,079
  • 4
  • 27
  • 32
1

You just run the program under gdb, and the debugger with catch the SIGSEGV and show you the line and instruction that faulted. Then you just examine the variable and/or register values to see what's wrong. Usually it's a rogue pointer value, and trying to access it with GDB will give and error, so it's easy.

And yes, recompiling everything with -g would be helpful. The interviewer probably wanted you to describe how you'd figure out which file had the fault (gdb just tells you when it catches the signal) and just recompile that one with debug info. If there's 20,000 source files that might be useful, but with 3 or 4 files, what's the point? Even with larger projects, you usually end up chasing the bad pointer through 10 functions and 5 files anyway, so again, what's the point? Debug info doesn't cost anything at run time, although it costs disk space in an installation.

ams
  • 24,923
  • 4
  • 54
  • 75
0

one can use the following steps to debug segmentation fault using gdb 

$ gdb <exec name > 
$ r          //run the pgm
$ where 
$ f <1> <0>   //to view the function n variables 

$ list 

$ p <variable>
Baby Groot
  • 4,637
  • 39
  • 52
  • 71
user3282672
  • 1
0

Sounds like they are looking to set it up so that you can step through the code as it is running, you can do this with the command line version or I think you can get a GUI for GDB.

ColWhi
  • 1,077
  • 6
  • 16