Original address: https://www.cnblogs.com/flyinggod/p/13415862.html
related articles
1. Core file function, setting and usage ---- https://www.cnblogs.com/xiaodoujiaohome/p/6222895.html
2. Linux system settings ulimit and Core file generation- https://blog.csdn.net/zjb9605025/article/details/6553184
| 1 2 3 4 5 6 7 8 9 10 |
|
Core dump generation method
In the Linux environment, a process hangs due to an exception, and it is usually difficult to find the cause. However, the core file provided by the Linux kernel generally records the information of the process when it crashes. However, a switch needs to be set to generate a core file. The specific steps are as follows:
1. Check whether the switch for generating the core file is turned on, and enter the command
ulimit -a
The core file size in the first line is 0 and it is not enabled.
2. Use ulimit -c [kbytes] to set the core file size allowed by the system.
| 1 2 3 |
|
Execute the command ulimit -c unlimited, and then ulimit -a to view the core
In this way, the core file can be generated when the process crashes. This method can only take effect in the shell. If this setting is always effective, you need to do the following settings
| 1 2 |
|
Save and exit, restart the server, the changed file will take effect for a long time, or
source /etc/profile
Do not restart the server, use source to make the file effective immediately.
3. Specify the path and name of the generated file
By default, the file name generated by core dump is core, and it is located in the current directory of the program. The new core will overwrite the existing core. By modifying the /proc/sys/kernel/core_uses_pid file, you can control the storage location and file format of the core file.
vim /etc/sysctl.conf #Enter the edit mode and add the following two lines kernel.core_pattern=/tmp/corefile/core_%t_%e_%p kernel.core_uses_pid=0
Create a core directory under var, use
sysctl –p /etc/sysctl.conf
The modification will take effect immediately.
The named parameters of core_pattern are as follows:
%c The upper limit of the dump file size %e The dumped file name %g The actual group ID of the dumped process %h The host name %p The dumped process PID %s The signal that caused this coredump %t dump time ( The number of seconds since January 1, 1970) %u The actual user ID of the dumped process
4. Execute the command in the terminal: kill -s SIGSEGV $$, you can see that a core file is generated under /tmp/corefile, indicating that the setting has been successful.
The core file is not generated under the following conditions:
| 1 2 3 4 |
|
Principle of core dump generation
Coredump usually occurs when the process receives a certain signal. There are currently more than 60 signals on Linux. You can use the kill -l command to list them all.
For a specific signal, the application can write the corresponding signal processing function. If not specified, the default processing method is adopted. The default processing is the signal of coredump as follows:
| 1 2 |
|
We see that SIGSEGV is in it. Generally, this signal is generated when an array is out of bounds or when a null pointer is accessed. In addition, although this is the default, you can also write your own signal processing function to change the default behavior. You can Google for more signal related.
core dump file debugging
| 1 2 3 4 5 6 7 8 9 10 11 12 |
|
The above code is an example code that will generate coredump
At this time, a new core file is generated under this executable program
See where the process crashed
Locate the line of the crash
You can turn on the -g debugging switch when compiling
| 1 |
|
If you don’t want to set the coredum global mode, you only need to generate a core file that can locate the crash location for the current process. Only 4 operations are required.
| 1 2 3 4 |
|
One thing to note when compiling the above program, you need to bring the parameter -g, so that the generated executable program will bring enough debugging information. After compiling and running, you should be able to see the long-awaited "Segment Fault (core dumped)" or "Segment Fault (core dumped)" words. Check if there is a core or core.xxx file in the current directory. Use the classic debugger GDB under Linux, first load the program with the core file: gdb exefile core, here you need to pay attention to the core file must be generated by the exefile, otherwise the symbol table will not be uploaded. It looks like this after loading
| 1 2 3 4 5 6 |
|
We can see that we can directly locate the core, and write a read-only memory area in line 8 which causes the Segment Fault signal to be triggered. There is a little trick when loading the core. If you don't know in advance which program generated the core file, you can find one to replace it. For example, /usr/bin/w is a good choice. For example, if we use this method to load the core generated above, gdb will have a similar output
| 1 2 3 4 5 |
|
You can see that GDB has already reminded you which program generated this core.
GDB common operations
The above program is relatively simple, and the problem can be found directly without additional operations. This is not the case in reality. It is often necessary to perform single-step tracking, setting breakpoints and other operations to locate the problem smoothly. Some common operations of GDB are listed below.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 |
|