Linux generates core files and conditions that do not produce core files __linux

Original: http://team.eyou.com/?p=27

Linux, produces core files, and does not produce core file conditions:

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, almost all C programmers have errors that are "segment errors." It is also the most difficult to detect the cause of a mistake. Here we analyze the generation of the core file for "segment error" and how we can use the core file to find where the crash occurred.

What is core file

When a program crashes, a stored image of the process is replicated in the core file of the current working directory of the process. The core file is just a memory image (plus debugging information), mainly for debugging.

A core file is generated when the program receives the following UNIX signal:

Name	Description	ANSI C posix.1	SVR4 4.3+bsd	Default action
Sigabrt	Abnormal termination (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 directives	. .	. .	Terminate W/core
Sigiot	Hardware failure		. .	Terminate W/core
Sigquit	Terminal Exit character	.	. .	Terminate W/core
SIGSEGV	Invalid store access	. .	. .	Terminate W/core
Sigsys	Invalid system call		. .	Terminate W/core
Sigtrap	Hardware failure		. .	Terminate W/core
Sigxcpu	Exceeding CPU limit (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 replicated in the core file of the current working directory of the process (the file name is core, which can be seen as part of the UNIX functionality long before). Most Unix debuggers use core files to check the state of the process at the end of the procedure.

The core file is not the posix.1 part, but the implementation features of many UNIX versions. Unix version 6th does not have a check condition (a) and (b), and its source code contains the following instructions: "If you are looking for a protection signal, then when the setting-user-id command executes, a lot of this signal will be generated." 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 identification to the core file, so it is an improved feature.

"Hardware Failure" in the table corresponds to the hardware failure of the implementation definition. Many of these names are taken from Unix's earlier implementations on DP-11. Check the Manual of the system you are using to determine exactly what type of error these signals correspond to.

These signals are described in more detail below.

• This signal is generated when SIGABRT calls the Abort function. The process terminated abnormally.

• Sigbus Indicates a hardware failure defined by an implementation.

• sigemt Indicates a hardware failure defined by an implementation.

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

• 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 directive.

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

• Sigiot This indicates a hardware failure defined by an implementation.

The name IoT is derived from the abbreviation of PDP-11 for the input/output trap (input/output trap) instruction. Earlier versions of System V, generated by the abort function. SIGABRT is now being used for this.

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

All processes in the 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 made an invalid storage access.

The name SEGV says "paragraph violation (segmentation violation)".

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

However, the parameters that indicate the type of system call are not valid.

• Sigtrap Indicates a hardware failure defined by an implementation.

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

• 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 the process exceeds its soft file length limit, SVR4 and 4.3+BSD generate this signal.

Excerpt from the 10th Chapter of UNIX Environment Advanced programming.

using the core file to debug a program

Look at the following example:

/*core_dump_test.c*/

1 #include <stdio.h>

2

3 const char *STR = "Test";

4

5 void Core_test ()

6 {

7 str[1] = ' T ';

8}

9

Ten int main ()

11 {

Core_test ();

13

return 0;

15}

Compiling:

[Zhanghua@localhost core_dump]$ gcc–g core_dump_test.c-o core_dump_test

If you need to debug your program, use GCC compile-time with the-G option, which makes it easier to find the wrong place when you debug the core file.

Execution:

[Zhanghua@localhost core_dump]$./core_dump_test

Segment Error

A "segment error" occurred while running the Core_dump_test program, but no core file was generated. This is because the system 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.

[Zhanghua@localhost core_dump]$ Ulimit-c

0

[Zhanghua@localhost core_dump]$ ulimit-c 1000

[Zhanghua@localhost core_dump]$ Ulimit-c

1000

-c Specifies the size of the core file to be modified, 1000 specifies the core file size. You can also limit the size of the core file, such as:

[Zhanghua@localhost daemon]# Ulimit-c Unlimited

[Zhanghua@localhost daemon]# 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:

[Zhanghua@localhost core_dump]$./core_dump_test

Segment error (Core dumped)

[Zhanghua@localhost core_dump]$ ls core.*

core.6133

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

Mode core file

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

[Zhanghua@localhost core_dump]$ file core.6133

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

GDB can be used to debug core files under Linux.

[Zhanghua@localhost core_dump]$ gdb core_dump_test core.6133

GNU gdb Red Hat Linux (5.3POST-0.20021129.18RH)

Copyright 2003 Free Software Foundation, Inc.

The GDB is free software, covered by the GNU general public License, and your are

Welcome to change it and/or distribute copies of it under certain conditions.

Type ' show copying ' to the conditions.

There is absolutely no warranty for GDB. Type ' show warranty ' for details.

This GDB is configured as "I386-redhat-linux-gnu" ...