Determine the line of code that causes a segmentation fault

Question

How does one determine where the mistake is in the code that causes a segmentation fault   Can my compiler  gcc  show the location of the fault in the program

User · Answer

Lucas s answer about core dumps is good  In my  cshrc I have   alias core  ls -lt core  echo where   gdb -core core -silent  echo   n     to display the backtrace by entering  core   And the date stamp  to ensure I am looking at the right file      Added  If there is a stack corruption bug  then the backtrace applied to the core dump is often garbage  In this case  running the program within gdb can give better results  as per the accepted answer  assuming the fault is easily reproducible   And also beware of multiple processes dumping core simultaneously  some OS s add the PID to the name of the core file

User · Answer

All of the above answers are correct and recommended  this answer is intended only as a last-resort if none of the aforementioned approaches can be used   If all else fails  you can always recompile your program with various temporary debug-print statements  e g  fprintf stderr   CHECKPOINT REACHED     s  i n     FILE      LINE      sprinkled throughout what you believe to be the relevant parts of your code   Then run the program  and observe what the was last debug-print printed just before the crash occurred -- you know your program got that far  so the crash must have happened after that point   Add or remove debug-prints  recompile  and run the test again  until you have narrowed it down to a single line of code   At that point you can fix the bug and remove all of the temporary debug-prints   It s quite tedious  but it has the advantage of working just about anywhere -- the only times it might not is if you don t have access to stdout or stderr for some reason  or if the bug you are trying to fix is a race-condition whose behavior changes when the timing of the program changes  since the debug-prints will slow down the program and change its timing

User · Answer

Also  you can give valgrind a try  if you install valgrind and run  valgrind --leak-check full  lt program gt    then it will run your program and display stack traces for any segfaults  as well as any invalid memory reads or writes and memory leaks  It s really quite useful

User · Answer

GCC can t do that but GDB  a debugger  sure can  Compile you program using the -g switch  like this   gcc program c -g   Then use gdb     gdb   a out  gdb  run  lt segfault happens here gt   gdb  backtrace  lt offending code is shown here gt    Here is a nice tutorial to get you started with GDB   Where the segfault occurs is generally only a clue as to where  the mistake which causes  it is in the code  The given location is not necessarily where the problem resides

User · Answer

You could also use a core dump and then examine it with gdb  To get useful information you also need to compile with the -g flag   Whenever you get the message    Segmentation fault  core dumped    a core file is written into your current directory  And you can examine it with the command   gdb your program core file   The file contains the state of the memory when the program crashed  A core dump can be useful during the deployment of your software    Make sure your system doesn t set the core dump file size to zero  You can set it to unlimited with   ulimit -c unlimited  Careful though  that core dumps can become huge

User · Answer

There are a number of tools available which help debugging segmentation faults and I would like to add my favorite tool to the list  Address Sanitizers  often abbreviated ASAN    Modern   compilers come with the handy -fsanitize address flag  adding some compile time and run time overhead which does more error checking   According to the documentation these checks include catching segmentation faults by default  The advantage here is that you get a stack trace similar to gdb s output  but without running the program inside a debugger  An example   int main       volatile int  ptr    int  0     ptr   0        gcc -g -fsanitize address main c     a out AddressSanitizer DEADLYSIGNAL                                                                     4848  ERROR  AddressSanitizer  SEGV on unknown address 0x000000000000  pc 0x5654348db1a0 bp 0x7ffc05e39240 sp 0x7ffc05e39230 T0    4848  The signal is caused by a WRITE memory access    4848  Hint  address points to the zero page       0 0x5654348db19f in main  tmp tmp s3gwjqb8zT main c 3      1 0x7f0e5a052b6a in   libc start main   lib x86 64-linux-gnu libc so 6 0x26b6a       2 0x5654348db099 in  start   tmp tmp s3gwjqb8zT a out 0x1099   AddressSanitizer can not provide additional info  SUMMARY  AddressSanitizer  SEGV  tmp tmp s3gwjqb8zT main c 3 in main   4848  ABORTING   The output is slightly more complicated than what gdb would output but there are upsides    There is no need to reproduce the problem to receive a stack trace  Simply enabling the flag during development is enough  ASANs catch a lot more than just segmentation faults  Many out of bounds accesses will be caught even if that memory area was accessible to the process         That is Clang 3 1  and GCC 4 8

[c++] Determine the line of code that causes a segmentation fault?

Examples related to c++

Examples related to c

Examples related to debugging

Examples related to segmentation-fault