"Z" segment error segment fault positioning, i.e. core dump file and GDB location

The use of C + + development system sometimes has a segment error, that is, segment Fault. This kind of error program crashes directly, usually without any useful information output, it is difficult to locate the bug, so it is impossible to solve the problem. Today we present the core dump file and debug it using GDB to locate the segment error problem. This article is also used for memo.

First, Core dump

Core dump is also known as the kernel dump, and when the program runs abnormally exits, the operating system stores the current memory state of the program in a core file called the core dump file.

The system does not generate a core dump file by default and can be viewed and set using the Ulimit command.

View. Using the ulimit-c or ULIMIT-A command to view the core dump file size, if the core file size is 0, indicates that the system does not automatically generate a core dump file at this time, as shown in case 1.

Figure 1

Set up. We can configure the system by setting the core file size to unrestricted unlimited with the Ulimit-c Unlimited command, so that it can automatically generate Coredump files, as shown in action 2.

Figure 2

Second, paragraph error procedure

We write a simple section error program named Core_test.cpp, the code is as follows. Compile and run, the system automatically produces the core file, 3.

#include<assert.h> int main() { assert(0); return 0;}

Figure 3

Third, core file naming

In a production environment, there are many programs running on one server, and if all of the program's core dump files are automatically named core, it can cause some confusion. To do this, we can set the system to specify more information when naming the core dump file.

The process number. The following settings allow you to make the core dump file a core.pid form. As shown in 4, the system automatically generates the core.3430 file.

echo "1" >/proc/sys/kernel/core_uses_pid

Figure 4

More information. The following settings allow you to make the core dump file a core-exe-pid-time form. As shown in 4, the system automatically generates the core-core_test-3465-1416037828 file.

echo “/coredir/core-%e-%p-%t” > /proc/sys/kernel/core_pattern/

Figure 5

If we want to further customize the name of the core file, we can set it according to the information in table 1.

Table 1

Percent of a single% character %p Process ID %u process actual User ID The actual group ID of the%G process %s causes the signal for this core dump %t Core Dump timestamp (number of seconds from January 1, 1970) %H Host Name %e program file name

Iv. using GDB to locate the core dump error

Some bloggers mentioned using the Gdb–c core with the where command to locate the error. Perhaps because of the configuration, I actually discovered that if you use Gdb–c core, the location information you get is not readable, as shown in 6.

Figure 6

In the end, I use the gdb core_test Core command (where Core_test is the executable program for dump, core is the core file), after entering GDB, and then using the where command, you can locate the location of the code where the dump occurred. And it has good readability, as shown in detail in 7.

Figure 7

Reference

http://blog.csdn.net/ithomer/article/details/5945152

"Z" segment error segment fault positioning, i.e. core dump file and GDB location