LINUX Core Dump Detailed

Transferred from: Http://blog.163.com/[email protected]/blog/static/8442751200710255441327/

1. Preface: Some programs can be compiled, but at run time there will be segment fault (segment error). This is usually caused by a pointer error. But this is not like a compile error prompt to file-and-line, but there is no information, making our debugging difficult to get up.
2. GDB: One way to do this is to use GDB's step step to find out. This is possible in a short code, but to get you to step into a tens of thousands of lines of code, I think you will dislike the name of the programmer, and call him a debugger. We have a better idea, this is the core file.
3. Ulimit: If you want the system to produce a core file in case of an error caused by a signal interruption, we need to set it in the shell as follows: #设置core大小为无限 Ulimit-c unlimited #设置文件大小为无限 Ulimit Unlimited
These need to have root permission, each time you reopen interrupts under Ubuntu, you need to re-enter the first command above to set the core size to infinity.
4. View the core file with GDB: Below we can take the core dump in case of an error caused by a run-time signal. After core dump occurs, use GDB to view the contents of the core file to locate the row in the file that raised the core dump. GDB [exec file] [core file] such as: GDB./test Test.core After entering GDB, use the BT command to view the backtrace to check where the program is running, and to locate the file-and-line of core dump.

When our program crashes, it is possible for the kernel to map the current memory of the program to the core file, so that the programmer can find out where the program is having problems. Most often, the error that almost all C programmers have had is "segment error". is also the most difficult to isolate the cause of the problem of a mistake. Below we will analyze the generation of the core file for "segment error" and how we can use the core file to find the place where the crash occurred.

What is a core file

When a program crashes, the stored image of the process is copied in the core file of the current working directory of the process. The core file is simply a memory image ( plus debugging information ), which is used primarily for debugging purposes.

The core file is generated when the program receives the following UNIX signals:

Name	Description	ANSI C posix.1	SVR4 4.3+bsd	Default action
Sigabrt	Aborted (abort)	. .	. .	Terminate W/core
Sigbus	Hardware failure	.	. .	Terminate W/core
Sigemt	Hardware failure		. .	Terminate W/core
SIGFPE	Arithmetic exceptions	. .	. .	Terminate W/core
Sigill	Illegal hardware instructions	. .	. .	Terminate W/core
Sigiot	Hardware failure		. .	Terminate W/core
Sigquit	Terminal Exit character	.	. .	Terminate W/core
SIGSEGV	Invalid storage access	. .	. .	Terminate W/core
Sigsys	Invalid system call		. .	Terminate W/core
SIGTRAP	Hardware failure		. .	Terminate W/core
Sigxcpu	CPU limit exceeded (Setrlimit)		. .	Terminate W/core
Sigxfsz	File length limit exceeded (setrlimit)		. .	Terminate W/core

In the system default Action column, "Terminate W/core" means that the stored image of the process is copied in the core file of the current working directory of the process (the file is called core, which can be seen as part of a UNIX feature long before). Most Unix debuggers use the core file to check the state of the process at the time of termination.

The creation of the core file is not part of the posix.1, but is the implementation feature of many UNIX versions. Unix version 6th does not have a check condition (a) and (b), and its source code contains the following description: "If you are looking for a protection signal, it is possible to generate a large number of such signals when the set-user-id command executes." 4.3 + BSD produces a file named Core.prog, where prog is the first 1 6 characters of the program name being executed. It gives some kind of identity to the core file, so it's an improved feature.

The hardware failure in the table corresponds to the hardware failure that is defined by the implementation. Many of these names were taken from the previous implementations of Unix on DP-11. Please review the Manual of the system you are using to determine exactly which error types these signals correspond to.

These signals are described in more detail below.

? This signal is generated when the Abort function is called by SIGABRT . The process terminated abnormally.

? Sigbus indicates an implementation-defined hardware failure.

? SIGEMT indicates an implementation-defined hardware failure.

EMT This name comes from PDP-11 's emulator trap directive.

? SIGFPE This signal represents an arithmetic operation exception, such as dividing by 0, floating-point overflow, and so on.

? Sigill This signal indicates that the process has executed an illegal hardware instruction.

4.3BSD generates this signal by the abort function. SIGABRT is now used for this.

? Sigiot This indicates an implementation-defined hardware failure.

The name IoT comes from PDP-11 's abbreviation for the input/output trap (Input/output trap) directive. Earlier versions of System V, this signal is generated by the abort function. SIGABRT is now used for this.

? Sigquit When the user presses the exit key on the terminal (generally using ctrl-\), this signal is generated and sent to the front

All processes in a process group. This signal not only terminates the foreground process group (as SIGINT did), but also produces a core file.

? SIGSEGV indicates that the process has made an invalid storage access.

The name SEGV represents "segment violation (segmentation violation)".

? Sigsys indicates an invalid system call. For some unknown reason, the process executes a system call instruction,

However, it indicates that the parameters of the system invocation type are invalid.

? SIGTRAP indicates an implementation-defined hardware failure.

This signal name is derived from the trap instruction of the PDP-11.

? sigxcpu SVR4 and 4.3+BSD support the concept of resource constraints. This signal is generated if the process exceeds its soft c P u time limit.

? Sigxfsz If a process exceeds its soft file length limit, SVR4 and 4.3+BSD generate this signal.

Excerpt from the 10th chapter of advanced Programming for the UNIX environment.

Use Core file Debug Program

Look at the following example:

  #include <stdio.h> const char * str = "Test"; void core_test () {     str[1] = ' T '; }
int Main ()     core_test ();     return 0;

compilation: gcc –g core_dump_test.c-o core_dump_test

If you need to debug a program, use gcc compile with the- g option, so debugging the core file is easier to find the wrong place.

Execution: ./core_dump_test Segment Error

run core_dump_test program appears " Segment Error ", but did not produce core file. This is because the system defaults to core file size is 0 , so it was not created. You can use ulimit command to view and modify core the size of the file. ulimit-c 0 ulimit-c ulimit-c 1000

- C specifies the size of the core file to be modified, and the core file size is specified. You can also make no restrictions on the size of the core file, such as:

Ulimit-c Unlimited ulimit-c Unlimited

If you want the modification to take effect permanently, you need to modify the configuration file, such as . Bash_profile,/etc/profile , or /etc/security/limits.conf.

Execute again: ./core_dump_test Segment Error (core dumped) ls core.* core.6133

You can see that a core.6133 file has been created . 6133 is the process IDthat the core_dump_test program runs.

Mode Core The file core file is a binary file and requires the appropriate tools to parse the memory image of the program when it crashes.

File core.6133

Core.6133:elf 32-bit LSB Core file Intel 80386, version 1 (SYSV), Svr4-style, from ' Core_dump_test '

You can use GDB to debug a core file under Linux .

GDB core_dump_test core.6133

GNU gdb Red Hat Linux (5.3POST-0.20021129.18RH)Copyright 2003 Free Software Foundation, Inc.GDB is free software, covered by the GNU general public License, and you areWelcome to change it and/or distribute copies of it under certain.Type "show copying" to see the conditions.there is absolutely no warranty for GDB. Type "Show warranty" for details. This GDB is configured as "I386-redhat-linux-gnu" ...Core is generated by './core_dump_test '.Program terminated with signal one, segmentation fault.Reading symbols From/lib/tls/libc.so.6...done.Loaded Symbols for/lib/tls/libc.so.6Reading symbols From/lib/ld-linux.so.2...done.Loaded Symbols for/lib/ld-linux.so.2#0 0x080482fd in Core_test () at Core_dump_test.c:77 str[1] = ' T ';(GDB) where#0 0x080482fd in Core_test () at Core_dump_test.c:7 #1 0x08048317 in Main () @ core_dump_test.c:12 #2 0x42015574 in __libc_start_main () from/lib/tls/lib C.so.6

When you type wherein GDB , you see the stack information when the program crashes (the list of all called functions before the current function (including the current function),gdb shows only the last few), It is easy for us to find our program in the last crash when the code called the core_dump_test.c 7 line, causing the program to crash. Note: The option- gis added when compiling the program. You can also try other commands, such as Fram,list , and so on. For more detailed usage, consult the GDB documentation.

Core Where is the file created?

Created under the current working directory of the process. Usually the same path as the program. However, if the ChDir function is called in the program, it is possible to change the current working directory. The core file is then created under the path specified by ChDir. There are a lot of programs that crash, but we can't find where the core files are located. It is related to the ChDir function. Of course the program crashes and does not necessarily produce core files.

When not to produce a core file

The core file is not generated under the following conditions: (a) The process is set-user-id, and the current user is not the owner of the program file, (b) The process is set-group-id, and the current user is not the group owner of the program file, (c) The user does not have permission to write the current working directory; The license for the core file (assuming that the file does not exist before this) is usually a user read/write, group read, and other read.

Using GDB to debug the core file, we are no longer helpless when we encounter a program crash.

LINUX Core Dump detailed (GO)