coredump and kdump under Linux

foreword

When we introduced process waiting before , we introduced that the parent process will wait for the child process and recycle the running end status of the child process (status output parameter): refer to the blog

insert image description here

When the process is killed by a signal due to some hardware interruptions, abnormalities, etc., the coredump flag bit of the exit code 8 will be set to 1, so that its parent process will detect it and generate a core snapshot file for subsequent use Find the cause of the exception;


What is coredump?

Coredump is translated as core dump . This mechanism will take a snapshot when a user-level process hangs abnormally (kdump is introduced below for a kernel-level process crash), and saves the memory, registers, stack and other operating information when the exception occurs. These data are stored as a core file, which can be further viewed and analyzed through debuggers such as gdb;


run exception code

insert image description here

Exception code execution result

insert image description here


View the core files with extra local files

insert image description here

In fact, core.xxx, this xxx part is the pid corresponding to the abnormal process at that time!

Note: If the core file cannot be generated, it is because the default core file size of the system is 0 bytes, you need to set it with the command ulimit -c xxx;

ulimit directive:

  • S: Indicates soft limit, and an alarm will be given if the value exceeds the set value.
  • H : Indicates a hard limit, and an error will be reported if the value exceeds the set value.
  • a : List the values ​​of all resource limits of the system
  • c: When an error occurs in some programs, the system may write some running information of the program in the memory into a file (for debugging), and this file is called a core file. This is to limit the maximum capacity of each core file
  • d: the maximum value of each process data segment
  • f: The maximum file size that can be created by the current shell
  • l: The maximum value of physical memory that can be locked
  • m: The maximum value of resident memory that can be used
  • n: The maximum number of file handles that each process can open at the same time
  • p: the maximum value of the pipeline
  • s: the maximum value of the stack
  • t: The maximum time each process can use the CPU
  • u: The maximum number of concurrent processes run by each user
  • v: The maximum virtual memory available to the current shell

img


Gdb debugging brings the core file

insert image description here

It can be seen that when gdb debugs the 2 program this time, the corresponding core file is added later (note that gcc must be compiled with -g to generate the debug version of the program to be debugged with gdb), and it will directly jump to the abnormal position, displaying The abnormal signal sent by the OS is described and the cause of the abnormality is described, which is helpful for us to locate the abnormality in the debugging process, etc.;


kdump mechanism

Kdump is kernel dump, kernel crash dump, its function is the same as coredump core dump, the scene is different, coredump is when the user-level program hangs up, and Kdump enters the second kernel capture through kexec when the kernel system-level process crashes Generated crash dump file;

The use of Kdump is more complicated, and many options need to be configured;

Rough process: Through the kexec mechanism –> after the first kernel crashes, load the second (captured) kernel into the memory, and switch to the second kernel to run at the moment of the crash, and at the same time use a series of non-gdb in the second kernel Debugging tool to debug and analyze the cause of the crash!

Guess you like

Origin blog.csdn.net/wtl666_6/article/details/129737794