Segmentation fault (SIGSEGV) location method

When we develop programs under Linux, if the program code is not rigorous, we often encounter problems

segmentation fault

Error, the result of this error is that the program will hang up directly, it is difficult to locate the problem code in the program.

reason

Segmentation fault is often referred to as memory leak / overflow: when a process executes an invalid memory reference or breaks, SIGSEGV signal will be triggered, and the kernel’s default action is to terminate the process.
For example, we use illegal pointers:


 1 #include <stdio.h>
 2 #include <string.h>
 3 
 4 int main(void)
 5 {
 6         char *str = "abcd123";
 7         char *p = NULL;
 8         char a;
 9 
10         p = strstr(str, "456");
11 
12         a = *p;
13 
14         return 0;
15 
16 }

When the above code is executed, there will be an error in memory. Because P is null, if we access the null pointer, there will be an error.
Revision:

char *str = "abcd123";
char *p = NULL;
char a;
p = strstr(str, "456");
if(p != NULL){
  a = *p;
}

So the key is to program strictly.

Solutions

    using GDB to debug and run, which needs to be positioned step by step, is obviously not optimal. Using the core file, Linux will generate a core file for SIGSEGV fault by default, which records the stack information when the fault occurs. The GDB program core can quickly trace the problem code. However, we need to add the compilation parameter – G
when compiling

gcc -g a.c -o test

GDB view command: BT and where

jsq@jsq:/opt/tmp/sigsegv-test$ gdb ./test core
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...done.
[New LWP 5868]
Core was generated by `./test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000561a6e023680 in main () at a.c:12
12		a = *p;
(gdb) bt
#0  0x0000561a6e023680 in main () at a.c:12
(gdb) where
#0  0x0000561a6e023680 in main () at a.c:12
(gdb) 

As you can easily see from the above information, the problem is located at line 12 of A.C.

Unable to generate core file resolution

The core file is usually generated in the current directory where the program is executed. If it cannot be generated, there are two common reasons:
1. Linux kernel is limited. You need to set it through ulimit – C, and you can check whether there are restrictions through ulimit – A

jsq@jsq:/opt/tmp/sigsegv-test$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15071
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 15071
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

In the figure above, we can see that the size of the core file is 0, which indicates that it is forbidden. We can set the size through the – C option, for example:

ulimit -c 1024

Set to 1024
2. The current program does not have “write” permission in the current directory
this has been encountered before. In some hardware configurations or special paths, if the core file is not 0, the core file still cannot be generated. At this time, we need to consider the issue of write permission (LS – L view), which mainly involves the permissions of program users and user groups, We can set users and user groups through chown and chrgp commands, for example:

chown test root
chrgp test root

Set the user and user group of the test program to root.

Summary

Segmentation fault is an abnormal memory fault. The fastest way to locate it is to trace the core file, so it is necessary to set the Linux environment to be able to run and generate the core file.

Read More: