Identify a line of code that causes a segmentation error?

Question

How to determine where the error in our code that causes the segmentation error ?

After writing some code to determine where I have a segmentation error, can my compiler ( gcc ) show me the location of the error in my program?

Answer 1

GCC cannot do this, but GDB is sure. Compile the program using the -g switch, for example:

 gcc program.c -g 

Then use gdb:

 $ gdb ./a.out (gdb) run <segfault happens here> (gdb) backtrace <offending code is shown here> 

Here is a good tutorial to get you started with GDB.

Answer 2

Alternatively, you can try Valgrind: if you install Valgrind and run valgrind --leak-check = full, it will run your program and display stack traces for any segfaults, as well as any invalid memory reads or writes and memory leaks. This is really helpful.

Answer 3

You can also use a kernel dump and then examine it with gdb. To get useful information, you also need to compile the -g flag.

Whenever you receive a message:

  Segmentation fault (core dumped) 

The main file is written to your current directory. And you can check it with the command

  gdb your_program core_file 

The file contains the memory status when the program crashes. A core dump can be useful when deploying your software.

Make sure your system does not set the kernel dump file size to zero. You can install it without restrictions:

ulimit -c unlimited

Caution! that major landfills can become huge.

Answer 4

There are a number of tools available that help debug segmentation errors, and I would like to add my favorite tool to the list: Address Sanitizers (often abbreviated ASAN) .

Modern compilers come with a convenient -fsanitize=address , adding some compilation time and runtime, which makes more error checking.

According to the documentation, these checks include detection of segmentation errors by default. The advantage here is that you get a stack trace similar to GDB output, but without running the program inside the debugger. 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 a bit more complicated than gdb would output, but there are pluses:

• There is no need to reproduce the problem in order to get a stack trace. Simply turn on the flag during development.

• ASANs catch a lot more than just segmentation errors. Many unreachable accesses will be detected even if this area of ​​memory was available to the process.

---

¹ This is Clang 3.1 + and GCC 4.8 + .

Answer 5

Lucas answers about core dumps are good. In my .cshrc, I have:

 alias core 'ls -lt core; echo where | gdb -core=core -silent; echo "\n"' 

to display the return line by entering "core". And a date stamp to make sure I'm watching the file I need: (.

Added . If there is a stack corruption error, then backtracking applied to the core dump is often garbage. In this case, starting the program in gdb can give better results in accordance with the accepted answer (provided that the error is easily reproduced). Also, beware of dropping the kernel simultaneously by multiple processes; some operating systems add a PID to the name of the main file.