Segmentation fault (core dumped)

Transferred from: http://blog.chinaunix.net/uid-26748613-id-3182113.html

Reference: http://manpages.ubuntu.com/manpages/lucid/man5/core.5.html

Some programs can be compiled, but segment fault (segment errors) occur at run time. This is usually caused by a pointer error. However, this does not prompt a single line of the file as a compilation error, but does not have any information. One way is to use GDB's step, step-by-step search. But it's hard to imagine a tens of thousands of lines of code for step. We have a better idea, this is the core file.

If you want the system to produce a core file in the event of an error caused by a signal interruption, we need to set it in the shell as follows:

#设置core大小为无限 Ulimit-c Unlimited

#设置文件大小为无限 Ulimit Unlimited

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.

It is also important to note that if you run a lot of applications on your machine, the core you generate does not know which application was generated, and you can view it with the following commands: File core

Several questions:

1. What is core:

In the use of semiconductors as memory material, the human is the use of coils as memory material (inventor of Wang), the coil is called core, the memory of the coil is called the core memories. Now that the semiconductor industry has grown, no one has used the core memory, but in many cases people have called it core.

2. What is core Dump:

When we develop (or use) a program, the most feared is that the program is out of the way. Although the system is fine, we may still encounter the same problem next time. Then the operating system will dump the memory content of the program when it comes out (now usually written in a file called core), let us or debugger as a reference. This action is called core dump.

3. What files will be generated when Core dump:

Core dump, a file such as the core process number is generated.

4. Sometimes the program is down, but the core file is not generated.

Under Linux, there are some settings that indicate the resources available to the shell and to processes. can use

#ulimit-A to see these settings. (Ulimit is bash built-in Command)

As can be seen from here, if-C is displayed: Core file size. If this value is 0, the core file cannot be generated. So you can use: #ulimit-C 1024 or #ulimit-C unlimited to enable the core file. If the program generates a core file when an error occurs, segmentation fault (core dumped) is displayed.

5. Core dump file directory and naming rules:

/proc/sys/kernel/core_uses_pid can control whether a PID is added to the file name of the resulting core file, and if it is added, the content is 1, otherwise 0

You can modify this file by using the following command:

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

6. How to use the core file:

Under Linux, use:

#gdb-C Core.pid program_name

You can enter GDB mode.

Input where, you can indicate which line is down, which function, who is called and so on.

(GDB) where

or enter BT.

(GDB) bt

7. How to make a normal program down:

#kill-S SIGSEGV pid

8. See where the core file output is:

The directory where the coredump is stored is the current directory of the process, which is usually the directory where the command was launched to start the process. However, if you start with a script, the script may modify the current directory, and the actual current directory of the process will be different from the directory where the script was executed. You can then view the target of the/proc/< process PID>/CWD symbolic link to determine the actual current directory address of the process. Processes initiated through system services can also be viewed in this way.

Proc/sys/kernel/core_pattern can control where the core file is saved and the file name format.

You can modify this file by using the following command:

echo "/corefile/core-%e-%p-%t" >core_pattern

The core file can be generated uniformly into the/corefile directory, resulting in a file named core-command name-pid-timestamp

The following is a list of parameters:

%p-insert pid into filename add PID

%u-insert current UID to filename to add the present UID

%g-insert current GID into filename to add an existing GID

%s-insert signal that caused the coredump into the filename adds a signal that causes the core to be generated

%t-insert Unix time, the coredump occurred into filename when you add a core file when you build Unix

%h-insert hostname where the coredump happened into filename adds host name

%e-insert coredumping executable name into filename add command name

In Linux to ensure that the program crashes when generating coredump to be aware of these issues:

To ensure that the directory in which the coredump is stored exists and that the process has write access to the directory. The directory where the coredump is stored is the current directory of the process, which is usually the directory where the command was launched to start the process. However, if you start with a script, the script may modify the current directory, and the actual current directory of the process will be different from the directory where the script was executed. You can then view the target of the/proc/process PID>/CWD symbolic link to determine the actual current directory address of the process. Processes initiated through system services can also be viewed in this way.

If the program calls Seteuid ()/setegid () changes the active user or group of the process, the system does not generate coredump for these processes by default. Many service programs will call Seteuid (), such as MySQL, regardless of what user you use to run Mysqld_safe startup Mysql,mysqld The active user is always MSYQL user. If you have run a program with User A, but the user who sees the program in PS is B, then these processes are called seteuid. To enable these processes to generate core dumps, you need to/proc/sys/fs

Change the contents of the/suid_dumpable file to 1 (typically 0 by default).

Third, this is generally known, is to set a large enough core file size limit. The size of the core file that is generated when the program crashes is the amount of memory that the program consumes when it runs. However, the behavior of the program crashes can not be estimated as usual behavior, such as buffer overflow and other errors may cause the stack to be destroyed, so often the value of a variable is modified to a mess, and then the program uses this size to apply memory can cause the program more memory than usual. So no matter how little memory is used when the program is running properly, it's good to make sure that you build the core file or set the size limit to unlimited.

Four, abnormal exit will certainly generate core. There is no exception that does not generate a core exit.

If it is not normal to exit that is the signal caused by the program exit, some of the signals can really cause the program to exit but do not generate core.

SIGHUP terminating process terminal line hang-off

SIGINT terminating process Interrupt process

Sigquit establish core file termination process, and generate core file

Sigill Creating a core file illegal directive

SIGTRAP build core file tracking self-trapping

Sigbus establishing a core file bus error

SIGSEGV creating core file Segment Illegal error

SIGFPE creating a core file floating point exception

Sigiot creating a core file to perform I/O self-trapping

SIGKILL Terminate process Kill process

Sigpipe terminating a process writing data to a pipeline that does not have a read process

Sigalarm Terminating process timer to

SIGTERM terminating process software termination signal

SIGSTOP stop signal stop process non-terminal

SIGTSTP stop signal to stop the process terminal

Sigcont ignore signal continue execution of a stopped process

Sigurg ignoring signal I/O emergency signal

SIGIO ignoring the signal descriptor can be I/O

SIGCHLD Ignore signal Notify parent process when child process stops or exits

Sigttou Stop process background process write terminal

Sigttin Stop process background process read Terminal

SIGXGPU terminating process CPU time-out

SIGXFSZ termination process file length too long

Sigwinch ignoring signal window size changes

SIGPROF terminating process statistics distribution graph with timer to time

SIGUSR1 terminating a process user-defined signal 1

SIGUSR2 terminating a process user-defined signal 2

SIGVTALRM terminating the process virtual timer to

Set the possible signal on the handle to see if that is the case.