Linux core dump

1. Preface:
Some programs can be compiled, but segment fault (segment error) may occur during runtime. This is usually caused by pointer errors.
However, this does not prompt the file-> line like a compilation error, but does not have any information, making debugging difficult.

2. GDB:
One way is to use GDB step for further search.
It is feasible to put it in short code, but to let you step into a code of tens of thousands of lines, I think you will hate the programmer name and call it a programmer.
We still have a better solution, which is core file.

3. ulimit:
If you want the system to generate a core file when an error occurs due to signal interruption, you need to set it in shell as follows:
# Set the core size to unlimited
Ulimit-C Unlimited
# Set the file size to unlimited
Ulimit Unlimited

These require the root permission. In ubuntu, you need to re-enter the first command to set the core size to infinite.

4. Use GDB to view the core file:
Here we can dump the core when an error occurs due to the message number.
After a core dump occurs, use GDB to view the content of the core file to locate the line that causes the core dump in the file.
GDB [exec file] [core file]
For example:
GDB./test. Core
After entering GDB, run the BT command to check where the program is running and locate the core dump file-> line.

 

 

 

When our program crashes, the kernel may map the current memory of the program to the core file, so that programmers can find out where the program is faulty. Most often, the errors that almost all c programmers encounter are "segment errors. It is also the most difficult error to identify the cause of the problem. Next we will analyze the generation of core files for "segment errors" and how we can use core files to find the crash location.

What is a core file?

When a program crashes, the stored images of the process are copied to the core file in the current working directory of the process. The core file is only a memory image (with debugging information added) and is mainly used for debugging.

When the program receives the following UNIX signal, it will generate a core file:

Name	Description	Ansi c posix.1	Svr4 4.3 + BSD	Default action
SIGABRT	Abort)	..	..	Terminate w/Core
Sigbus	Hardware faults	.	..	Terminate w/Core
Sigemt	Hardware faults		..	Terminate w/Core
Sigfpe	Arithmetic exception	..	..	Terminate w/Core
Sigill	Invalid hardware instruction	..	..	Terminate w/Core
Sigiot	Hardware faults		..	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 faults		..	Terminate w/Core
Sigxcpu	CPU limit exceeded (setrlimit)		..	Terminate w/Core
Sigxfsz	Exceeds the file length limit (setrlimit)		..	Terminate w/Core

In the system default action column, "Terminate w/core" indicates that the stored image of the process is copied to the core file in the current working directory of the process (the file name is core, from this we can see that this feature was a part of UNIX long ago ). Most Unix debugging programs use core files to check the state of a process upon termination.

The generation of core files is not part of posix.1, but the implementation features of many UNIX versions. UNIX 6th does not have check conditions (a) and (B), and its source code contains the following instructions: "If you are looking for protection signals, when you run the-user-id command, a large amount of such signals may be generated ". 4.3 + BSD generates a file named core. prog, where prog is the first 6 Characters of the program name to be executed. It identifies a core file, so it is an improved feature.

The "hardware faults" in the table correspond to the hardware faults defined by the implementation. Many of these names are taken from UNIX earlier implementations on the DP-11. Please refer to the system manual you are using to determine exactly which error types these signals correspond.

These signals are described in detail below.

•SIGABRTThis signal is generated when the abort function is called. Abnormal Process Termination.

•SigbusIndicates a hardware fault defined by the implementation.

•SigemtIndicates a hardware fault defined by the implementation.

The emulator trap command from the PDP-11.

•SigfpeThis signal indicates an arithmetic operation exception, such as dividing by 0 and floating point overflow.

•SigillThis signal indicates that the process has executed an illegal hardware command.

4.3bsd this signal is generated by the abort function. SIGABRT is currently used here.

•SigiotThis indicates a hardware fault defined by the implementation.

The Iot name comes from the PDP-11's abbreviation for the input/output trap (input/output trap) command. This signal is generated by the abort function in earlier versions of System V. SIGABRT is currently used here.

•SigquitThis signal is generated when you press the return key (CTRL-/) on the terminal and sent to the front end.

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

•SIGSEGVIndicates that the process has performed an invalid storage access.

The segv name indicates "segment violation (segmentation violation )".

•SigsysIndicates an invalid system call. For some unknown reason, the process executes a System Call Command,

However, the parameter indicating the system call type is invalid.

•SigtrapIndicates a hardware fault defined by the implementation.

This signal name comes from the trap command for the PDP-11.

•SigxcpuSvr4 and 4.3 + BSD support the concept of resource restrictions. This signal is generated if the process exceeds its soft c p u time limit.

•SigxfszIf a process exceeds its soft file length limit, svr4 and 4.3 + BSD generate this signal.

From Chapter 10th of advanced programming in UNIX environment.

 

UseCoreFile debugging program

See the following example:

/* Core_dump_test.c */
# Include <stdio. h>
Const char * STR = "test ";
Void core_test (){
STR [1] = 'T ';
}

Int main (){
Core_test ();
Return 0;
}

Compile:
Gcc-G core_dump_test.c-O core_dump_test

If you need to debug the program, add the-G option during GCC compilation, which makes it easier to locate the error when debugging the core file.

Run:
./Core_dump_test
Segment Error

When you run the core_dump_test program, a "segment error" occurs, but no core file is generated. This is because the default core file size is 0, so it is not created. You can use the ulimit command to view and modify the size of the core file.
Ulimit-C 0
Ulimit-C 1000
Ulimit-C 1000

-C specifies the size of the core file, and 1000 specifies the size of the core file. You can also limit the size of the core file, for example:

Ulimit-C Unlimited
Ulimit-C Unlimited

If you want the change 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.68.0 file has been created. 6133 is the ID of the process where core_dump_test runs.

AdjustCoreFile
The core file is a binary file, and a corresponding tool is required to analyze the memory image when the program crashes.

File core.68.0

Core.6133: Elf 32-bit LSB Core File intel 80386, Version 1 (sysv), SVR4-style, from 'core _ dump_test'

In Linux, you can use GDB to debug core files.

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 are
Welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu "...
Core was generated by './core_dump_test '.
Program terminated with signal 11, segmentation fault.
Reading symbols from/lib/tls/libc. so.6...... done.
Loaded symbols for/lib/tls/libc. so.6
Reading 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: 7
7 STR [1] = 'T ';
(GDB) Where
#0 0x080482fd in core_test () at core_dump_test.c: 7
#1 0x08048317 in main () at core_dump_test.c: 12
#2 0x42015574 in _ libc_start_main () from/lib/tls/libc. so.6

If you type where in GDB, you will see the stack information when the program crashes (the list of all called functions before the current function (including the current function), GDB only displays the last few functions ), we can easily find that our program called core_dump_test.c 7th line of code during the final crash, resulting in program crash. Note: Add option-G when compiling the program. You can also try other commands, such as fram and list. For more detailed usage, see the gdb documentation.

CoreWhere is the file created?

Create in the current working directory of the process. It is usually in the same path as the program. However, if the chdir function is called in the program, the current working directory may be changed. The core file is created under the path specified by chdir. Many programs have crashed, but we cannot find the location of the core file. It is related to the chdir function. Of course, not all core files are generated when the program crashes.

When does the core file not be generated?

Core files are 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 has no permission to write the current working directory;
(D) The file is too large. Core File Permission (assuming that the file does not exist before) is usually User read/write, Group read and other reads.

Using GDB to debug core files, we are no longer helpless when a program crashes.