Core File details

In embedded development and testing, sometimes some problems can only be reproduced in a specific environment, and the reproduction time and conditions are hard to grasp, many tests may occasionally reproduce the problem, which makes debugging and modification inconvenient.

There is another situation that is difficult to track and Debug. In a large software project, the problem should be accurately located from tens of thousands of lines or even more code, it takes a lot of time to set breakpoints and perform one-step tracking.

These problems can be analyzed through core dump or post-event debugging (postmortem Debug. the main method is to save the memory image and debugging information of the program to a file when the program crashes. Then, the so-called core file is analyzed to find out the cause of the program crash. the name of core dump comes from the old industry name-when the memory is still a coil, it is called core. We can use GDB to analyze the core file to find the cause of the error.

Back in the day, a computer's main memory was built out of ferrite core. this is where the phrase "core dump" comes from: the main memory image of a program stored in a file on disk for Diagnosis

1. Introduction to core files

When a program crashes, it generally generates a core file under the specified directory. The core file is only a memory image (with debugging information added) and is mainly used for debugging.
 
2. enable or disable the generation of core files
Run the following command to prevent the system from generating core files:
Ulimit-C 0
The following command checks whether the option for generating the core file is Enabled:
Ulimit-
This command will display all user customization, with option-a representing "all ".
You can also modify the system file to adjust the core option.
In/etc/profile, the following statement is usually used to prohibit the generation of core files. This setting is reasonable:
# No core files by default
Ulimit-s-c 0>/dev/null 2> & 1
However, during the development process, you need to open the settings generated by the core file in a specific user environment for debugging purposes.
In the user's ~ /. Add ulimit-C unlimited to the bash_profile so that specific users can generate core files.
If ulimit-C 0 is used, the generation of core files is also prohibited, while ulimit-C 1024 limits the size of the generated core files to a maximum of kb.

3. Set the core dump file directory and naming rules for core dump.
/Proc/sys/kernel/core_uses_pid can be used to control whether the 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 or file name of the formatted core file. For example, the original file content is core-% E.
You can modify it as follows:
Echo "/corefile/Core-% E-% P-% t">/proc/sys/kernel/core_pattern
The generated core file is 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 add PID
% U-insert current uid into filename add current uid
% G-insert current GID into filename add current GID
% S-insert signal that caused the coredump into the filename added to generate core Signal
% T-insert UNIX time that the coredump occurred into filename UNIX time when the core file is generated
% H-insert hostname where the coredump happened into filename Add the Host Name
% E-insert coredumping executable name into filename add command name

4. Use a Core File
In the directory where the core file is located, type:
GDB-C Core
It starts the GNU Debugger to debug the core file, displays the program name that generates the core file, and terminates the program.
If you already know what program generates this core file, for example, if myserver crashes to generate core.12345, use this command for debugging:
GDB-C Core myserver
Next, we should learn how to use GDB.

5. A small method to test and generate core files
Directly enter the command:
Kill-s SIGSEGV $ (kill the current shell)

[Description]
When the program is down for unknown reasons, you can use core dump to dump out the memory for debugging.

Check whether core dump is enabled.
# Ulimit-
Core File size (blocks,-C) 0
Data seg size (Kbytes,-d) Unlimited
File size (blocks,-f) Unlimited
Max locked memory (Kbytes,-l) 4
Max memory size (Kbytes,-m) Unlimited
Open File (-N) 2048
Pipe size (512 bytes,-p) 8
Stack size (Kbytes,-S) 10240
CPU time (seconds,-T) Unlimited
Max user processes (-u) 7168
Virtual Memory (Kbytes,-v) Unlimited
The core file size is 0, indicating that the core dump is not enabled. Use ulimit-C unlimited to enable the core dump. Of course, unlimited can also be changed to the specific file size (unit: KB ), only unlimited is the easiest thing to do
Set the core dump file name and its location

View core dump
GDB -- core = core.12345 (core dump file name) or gdb exe name core name
BT to check where the program runs, backtrace
File EXE: Find the EXE location
L list Code
Where to show where to go down

Note: In some cases, the seteuid or setegid is used to change the users and groups in the city. For example, no matter who runs MySQL, MySQL runs as a MySQL user. In this case, core dump is not performed by default. You need to change the/proc/sys/fs/suid_dumpable content to 1 to request the system to generate core dump.