Linux core configuration and debugging

Http://www.cppblog.com/loky/archive/2008/12/10/69106.html

When ourProgramWhen the 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 fault	.	..	terminate w/Core
sigemts	hardware fault		..	terminate w/Core
sigfpe	arithmetic exception	..	..	terminate w/Core
sigill	illegal hardware commands	..	..	terminate w/Core
sigiot	hardware fault		..	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 fault		..	terminate w/Core
sigxcpu	exceeds the CPU limit (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. For Unix 6th, no conditions (a) and (B) are checked, andSource code"If you are looking for a protection signal, a large number of such signals may be generated when you set the-user-id command to execute ". 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.

•SigquitWhen you press the return key on the terminal (CTRL-\ is generally used), this signal is generated 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 the 7th line of core_dump_test.c during the final crash.Code, Causing 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.

 

Http://blog.csdn.net/KataDoc360/archive/2009/02/17/3902421.aspx

Linux core dump configuration and debugging

1. Core File generation switch and size limit
---------------------------------
1) Use the ulimit-C command to view the core file generation switch. If the result is 0, this function is disabled and core files are not generated.
2) use the ulimit-cfilesize command to limit the size of the core file (The unit of filesize is Kbyte ). If ulimit-cunlimited is used, the size of the core file is not limited. If the generated information exceeds this size, it will be cropped to generate an incomplete core file. When debugging this core file, GDB will prompt an error.

2. Name and path of the Core File
----------------------------
If the core file generated by the system does not contain any other extension names, it is all named core. The new core file will overwrite the original core file.
1)/proc/sys/kernel/core_uses_pid can control whether PID is added to the file name of the core file as an extension. If the file content is 1, the PID is added as the extension, and the generated core file format is core. xxxx. If it is 0, the generated core file is named core.
Run the following command to modify the file:
Echo "1">/proc/sys/kernel/core_uses_pid
2) proc/sys/kernel/core_pattern can control the core file storage location and file name format.
Run the following command to modify the file:
Echo "/corefile/Core-% E-% P-% t"> core_pattern, which can generate core files in the/corefile directory, the generated file name is core-command name-PID-timestamp.
The following is a list of parameters:
% P-insert PID into filename add PID
% U-insert current uid into filename add current uid
% G-insert current GID into filename add current GID
% S-insert signal that caused the coredump into the filename added to generate core Signal
% T-insert UNIX time that the coredump occurred into filename UNIX time when the core file is generated
% H-insert hostname where the coredump happened into filename Add the Host Name
% E-insert coredumping executable name into filename add command name

3. 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.

4. Use the core file for debugging ON THE DEVELOPMENT BOARD
-----------------------------
If the operating system of the Development Board is also Linux, the core debugging method is still applicable. If GDB is not supported on the Development Board, you can copy the Development Board environment (header files, libraries), executable files, and core files to Linux on the PC and run relevant commands.
Note: The executable file to be debugged must be added to-g during compilation so that the core file can display error information normally!

Notes:

In Linux, pay attention to the following issues to ensure coredump is generated when the program crashes:

1. Ensure that the directory where coredump is stored exists and the process has the write permission on the directory. The directory that stores coredump is the current directory of the process, which is generally the directory where the command was issued to start the process. However, if the script is started, the script may modify the current directory. In this case, the current directory of the process is different from the directory where the script was originally executed. In this case, you can view the target of the "/proc/<process pid>/CWD" symbolic link to determine the real current directory address of the process. You can also view the processes started by the system service in this way.

2. If the program calls seteuid ()/setegid () to change the valid user or group of the process, the system will not generate coredump for these processes by default. Many service programs call seteuid (), such as MySQL. No matter which user you use to run mysqld_safe to start MySQL, the effective user of mysqld is always the msyql user. If you run a program with user A, but the user who sees the program in PS is B, then these processes call seteuid. To allow these processes to generate core dump, you need to change the content of the/proc/sys/fs/suid_dumpable file to 1 (usually 0 by default ).

3. This is generally known as setting a large enough core file size limit. The core file size generated when the program crashes is the memory size occupied by the program running. However, when a program crashes, the behavior cannot be estimated as usual. For example, errors such as buffer overflow may cause the stack to be destroyed. Therefore, the value of a variable is often changed to a mess, then the program uses this size to apply for memory, which may cause the program to occupy more memory than usual. Therefore, no matter how little memory is occupied during normal running of the program, make sure to generate the core file or set the size limit to unlimited.