Summary of Linux kernel debugging methods Coredump

What is core dump?

Analysis of core dump is an effective way to debug Linux applications, like kernel debug crawl Ram dump, Core dump is mainly to get the application crash when the site information, such as the program Runtime memory, register state, stack pointers, memory management information, function call stack information.

Core dump, also known as "kernel dump," is a signal-based implementation of Linux. The signal in Linux is an asynchronous event-handling mechanism in which each signal should have a default exception-handling operation, which includes ignoring the signal (Ignore), pausing the process (stop), terminating the process (Terminate), terminating and producing core dump (core), and so on. Typically the following signals trigger core dump:

Under what circumstances will a core dump be generated?

The following scenario occurs when an application crash causes the core dump to occur:

1. Memory access is out of bounds (array out of bounds, string no \ n terminator, string read/write crossed)
2. Thread unsafe functions are used in multithreaded programs, such as non-reentrant functions
3. Multi-threaded Read and write data is not lock-protected (critical zone resources require mutually exclusive access)
4. Illegal pointer (such as null pointer exception or illegal address access)
5. Stack Overflow

How do I get the core dump?

Linux provides a set of commands to configure the core dump behavior:

1. ulimit–c see if the core dump mechanism is enabled, and if 0 does not produce a core dump by default, you can use the Ulimit–c Unlimited to enable core dump

2. Cat/proc/sys/kernel/core_pattern View the default save path for the core file, which is saved in the application's current directory by default, but if the application calls the ChDir () function to switch the current working directory, it will be saved in the corresponding working directory

3. Echo "/data/xxx/<core_file>" >/proc/sys/kernel/core_pattern Specify the path and file name for the core file, where core_file can use the following wildcard characters:

Percent of a single% character

Process ID of the%p dump process

The actual user ID of the%u dump process

%g The actual group ID of the dump process

%s causes the signal for this core dump

%t Core Dump time (number of seconds from January 1, 1970)

%H Host Name

%e program file name

4. ulimit–c [size] Specifies the core file size, the default is unlimited size, if customized, the size value must be greater than 4, the unit is block (1block = 512bytes)

How to analyze core dump?

We first write a program that artificially generates core dump and obtains the core dump file.

program, we create a core dump with the exception of 0 operations

The build run generates a floating-point number exception, which causes the core dump

The core file is generated under the current directory, using the file command to view the core file type

Find the core file type elf format, you can execute the file, use Readelf to view the elf file header information as follows

You can see through the Type field that the file is a core file

Before we talk about core dump to see the site information when the application crashes, we need the GDB command helper implementation, using the GDB test core (the test executable and the core file)

It prints out the cause of the core dump, the arithmetic exception, and prints out the problematic code line result = A/b; Note here that you are currently in a GDB debugging environment. The function call stack information can be displayed through Bt–n (backtrace), and N represents the number of call stack layers displayed. Because the TEST.C debugger does not involve function calls, we can only see the stack information of the main function, and if the program is wrong in the child function of the main function, it is possible to print more call stack information.

The disassemble command allows you to print an assembly code fragment when an error occurs, where the arrow points to the wrong line.

You can see that the div instruction is called for division, the divisor is -0x8 (%EBP), which refers to the value of the memory unit where the current stack base address is offset by 8 bytes, and EBP is the stack base address register. At the same time we can see the front through Movl $0x0, -0x8 (%EBP) Save 0 to the memory unit, proving that the divisor is 0.

Summary of Linux kernel debugging methods Coredump