How to use gdb to debug core files in Linux

1.core file

When a Segmentation fault (core dumped) error occurs during program execution, the program stops running and a core file is generated. The core file is a memory image of the program's running state. Using gdb to debug the core file can help us quickly locate the location where the program segmentation fault occurs. Of course, the -g compilation option should be added when compiling the executable program to generate debugging information.

When the memory accessed by the program exceeds the memory space given by the system, a Segmentation fault (core dumped) will occur. Therefore, the main situations in which segmentation faults occur are:

(1) Accessing a non-existent memory address;
(2) Accessing system-protected memory addresses;
(3) Array access out of bounds, etc.

Core dumped is also called core dump. When an exception occurs during program execution and the program exits abnormally, the operating system stores the program's current memory status in a core file, called core dumped.

Core means core memory, which is memory made of coils. Today, with the booming semiconductor industry, no one uses core memory anymore. However, in many cases, people still call memory core.

2. Control whether the core file is generated

(1) Use the ulimit -c command to view the core file generation switch. If the result is 0, it means that this function is disabled and no core file will be generated.

(2) Use the ulimit -c filesize command to limit the size of the core file (filesize is in KB). If the generated information exceeds this size, it will be truncated, resulting in an incomplete core file. When debugging this core file, gdb will prompt an error. For example: ulimit -c 1024.

(3) If ulimit -c unlimited is used, the size of the core file is unlimited.

The command ulimit -c unlimited in the terminal is only a temporary change and will not take effect after the reboot. To make a permanent change, there are three ways:

(1) Add a line ulimit -c unlimited in /etc/rc.local

(2) Add a line ulimit -c unlimited in /etc/profile

(3) Add the following two lines to the end of /etc/security/limits.conf:

@root soft core unlimited
@root hard core unlimited

3.core file name and generation path

The default file name of core is core.pid, where pid refers to the process ID of the program that generates the segmentation fault.
The default path is the current directory of the program that produced the segfault.

If you want to modify the name and generation path of the core file, the relevant configuration file is:
/proc/sys/kernel/core_uses_pid: Controls whether pid is added as an extension to the file name of the generated core file. If it is added, the file content is 1, otherwise it is 0.

/proc/sys/kernel/core_pattern: You can set the location and file name of the formatted core file, for example, the original file content is core-%e.
You can modify it like this:
echo "/corefile/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
The core file generated will be stored in the /corefile directory, and the generated file name is: core-command name-pid-timestamp.

The following is a list of parameters:

%p - insert pid into filename
%u - insert current uid into filename
%g - insert current gid into filename
%s - insert signal that caused the coredump into the filename
%t - insert UNIX time that the coredump occurred into filename Add the UNIX time when the core file was generated
%h - insert hostname where the coredump happened into filename
%e - insert coredumping executable name into filename adds the command name.

Generally, no modification is required and the default setting can be used.

4. Steps for gdb debugging core files

When using gdb to debug the core file to find the location of the segmentation fault in the program, it should be noted that the executable program needs to be compiled with the -g compilation command option.

The common steps for gdb debugging core files are as follows, and the first one is recommended.

Specific step one:

(1) Start gdb and enter the core file. The command format is: gdb [exec file] [core file].
Example usage: gdb ./test test.core.

(2) After entering gdb, find the segmentation fault location: where or bt

Usage example:

The specific location of the specific file in the source program can be located, and a segmentation error has occurred.

Specific step 2:

(1) Start gdb and enter the core file. The command format is: gdb –core=[core file].
Example usage: gdb –core=test.core.

(2) After entering gdb, specify the symbol table corresponding to the core file. The command format is: file [exec file].
Usage example:

Specific step three:

(1) Start gdb and enter the core file. The command format is: gdb -c [core file].
Example usage: gdb -core test.core.
(2) Other steps are the same as step 2.

5. Other methods to find the location of segmentation fault

You can use gdb for single-step debugging to find the location of the segmentation fault. For more information about gdb use cases, see:
A brief introduction to gdb usage under Linux.

The above is the details of how to use gdb to debug core files under Linux. For more information about Linux gdb debugging core files, please pay attention to other related articles on 123WORDPRESS.COM!