Core Dump Process Analysis

Gossip

Recent analysis of the problem, found in my environment, often have user-state process abnormal exit, but there is no core file generation, a simple look at the relevant kernel process, mark. Core Dump Fundamentals

When the application in the user state exception, such as common segment errors, usually generate core files, through GDB analysis of core files, basic can locate the problem.

The core file is actually a mirrored file of the current process address space, which contains all the information about the process in memory.

Linux system, the main core dump process described as: The process of running the process of the exception (such as segment error), the exception for the hardware escalation, can be understood as an interruption, abnormal escalation, the CPU after the execution of the current instructions will immediately stop the execution of the current context of the instructions, and enter the exception processing process: The general save context, jump to the corresponding interrupt vector at the execution, etc., specifically not detailed. After entering the exception handling process, will determine the exception of the CPU mode (X86 corresponding ring), if an exception, in the user state, the exception will only affect the current process, and then send the corresponding signal to the user state process, if it is a paragraph error, send the signal for SIGSEGV, If it is aborts, the signal normally sent is sigbus. If the exception is in the kernel state, the exception is fatal to the system, it will go into the kernel die process, will eventually panic, this situation will not generate core files, not the focus of discussion here. When the user state process has the time to process the signal (such as the scheduling), it will check the pending signal, and then processing, if the pending signal is found to be one of the sig_kernel_coredump_mask, it will enter the core file collection process, The core files are eventually generated based on user configuration. Code Analysis

Here in the ARM64 schema, the process of the core dump is explained by the flow of misaligned exceptions. Signal Sending

When the hardware detects alignment fault, it enters the corresponding exception handling function (other articles have analyzed the ARM64 exception handling process, can refer) processing, for alignment fault, will eventually enter the Do_mem_abort () function:

 * * Dispatch a data abort to the relevant handler.
 * *
asmlinkage void __exception do_mem_abort (unsigned long addr, unsigned int esr, struct pt_regs *regs
					 )
{
  /* extracts fault information from ESR
	/const struct Fault_info *inf = Fault_info + (ESR &);
	struct Siginfo info;

	if (!INF->FN (addr, ESR, regs)) return
		;
	/* We see in the messages print
	/Pr_alert ("Unhandled Fault:%s (0x%08x) at 0x%016lx\n",
		 Inf->name, ESR, addr);
	/* Fill Signal information * *
	Info.si_signo = inf->sig;
	Info.si_errno = 0;
	Info.si_code  = inf->code;
	Info.si_addr  = (void __user *) addr;
	/* Notifies the user of the state program or kernel die*/
	arm64_notify_die ("", Regs, &info, ESR);
}

The filling signal here is from ESR, for the alignment fault, the default is Sigbus signal, and then it goes into Arm64_notify_die ():

void Arm64_notify_die (const char str, struct pt_regs *regs, struct siginfo *info, int err) {/If the context in which an exception occurs is in user state, send the corresponding user-state process Signal/if (User_mode (regs)) {current->thread.fault_address = 0; current->thread.fault_code = err; Force_sig_info ( Info->si_signo, info, current); else {/If the kernel state is directly die, it will eventually panic*/die (str, regs, err);}

For the exception that occurs in the user state, the corresponding signal is sent, followed by the signal to send the main code flow (not detailed):

Force_sig_info-> 
  specific_send_sig_info->
    send_signal->
	  

Signal Processing

Signal processing is an asynchronous process, the kernel sends the signal to the user state process, the signal is not processed immediately, the signal processing time has several, the most important is when the process gets the dispatch, when the process gets the dispatch, will process the corresponding signal, the signal processing main code flow is as follows:

Do_signal->
  get_signal->
	sig_kernel_coredump->
	  

The specific code is not listed, a bit boring ~, here the main emphasis, what signal will eventually lead to core file generation, the key lies in the Sig_kernel_coredump_mask macro:

#define SIG_KERNEL_COREDUMP_MASK (
        rt_sigmask (sigquit)   |  Rt_sigmask (sigill)    |
	rt_sigmask (sigtrap)   |  Rt_sigmask (SIGABRT)   |
        rt_sigmask (SIGFPE)    |  Rt_sigmask (SIGSEGV)   |
	rt_sigmask (sigbus)    |  Rt_sigmask (sigsys)    |
        rt_sigmask (SIGXCPU)   |  Rt_sigmask (sigxfsz)   | \
	sigemt_mask	

The signal listed in this macro will produce a core file, the signal is not only the kernel can send, the user state of course can also send, the simplest is kill command, if to let a process to produce core files, you can send a signal directly (such as SIGSEGV, Sigbus), Of course, the simplest may be the Gcore command, the smallest damage, pull far away from the ~ related configuration

Finally, add the relevant configuration of core files, mainly two places:/proc/sys/kernel/core_pattern, can also be configured through sysctl.conf, to control the core file generation rules. ULIMIT-C controls the size of the core file, and if set to 0, the core file is not generated.

No more wordy.

Original address: http://happyseeker.github.io/kernel/2016/03/04/core-dump-mechanism.html