Shulou(Shulou.com)06/01 Report--

What this article shares with you is about how to understand coredump. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

First, what is coredump?

We often hear people say that the program core has dropped and needs to be fixed. Most of what we are talking about here refers to the abnormal exit or termination of the corresponding program during operation due to various exceptions or bug, and when certain conditions are met (why do we say that certain conditions need to be met here? A file called core will be generated.

Usually, the core file will contain the memory, register status, stack pointer, memory management information and all kinds of function call stack information when the program is running. We can understand that the current state of the program is stored to generate the first file, and many programs will generate a core file when something goes wrong. Analyze this file through tools. We can locate the corresponding stack call and other information when the program exits abnormally, find out the problem and solve it in time.

Second, the storage location of coredump files

The default storage location of the core file is in the same directory as the corresponding executable program, and the file name is core. You can see the location of the core file through the following command:

Cat / proc/sys/kernel/core_pattern

The default value is core

Note: this refers to the creation under 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 have been changed. The core file is created under the path specified by chdir. A lot of programs crashed, but we couldn't find where to put the core file. Has something to do with the chdir function. Of course, core files are not always generated when the program crashes.

The program code is as follows: the generated core file will be stored in / data/coredump/wd instead of in the same directory as the executable file.

You can change the storage location of the coredump file with the following command, if you want to generate the core file to the / data/coredump/core directory:

Echo "/ data/coredump/core" > / proc/sys/kernel/core_pattern

Note that the current user here must have write access to / proc/sys/kernel/core_pattern.

By default, the core files generated by the kernel when coredump are placed in the same directory as the program, and the file name is fixed to core. Obviously, if multiple programs generate core files, or if the same program crashes multiple times, the same core file will be overwritten repeatedly, so it is necessary to name the core files generated by different programs separately.

We can specify the file name of the coredump file generated by the kernel by modifying the parameters of kernel. For example, use the following command to cause kernel to generate an core dump file named core.filename.pid format:

Echo "/ data/coredump/core.%e.%p" > / proc/sys/kernel/core_pattern

After this configuration, the resulting core file will have the crashed program name and its process ID. The above% e and% p will be replaced with the program file name and the process ID.

If the directory delimiter "/" is included in the above file name, the generated core file will be placed in the specified directory. To be clear, there is another coredump-related setting in the kernel, which is / proc/sys/kernel/core_uses_pid. If the contents of this file are configured to 1, then even if% p is not set in core_pattern, the final generated core dump file name will still be added with the process ID.

Third, how to judge whether a file is a coredump file?

In the unix-like system, the main format of the coredump file itself is also the ELF format, so we can judge by the readelf command.

You can see that the type of the Type field in the ELF file header is: CORE (Core file)

You can quickly determine through a simple file command:

Fourth, a summary of some conditions for the generation of coredum

1. To generate coredump, you first need to confirm the ulimit-c of the current session. If 0, the corresponding coredump will not be generated and needs to be modified and set.

Ulimit-c unlimited (can generate coredump without size limit)

If you want even the corresponding character size, you can specify:

Ulimit-c [size]

As you can see, the unit of size here is blocks, which is usually 1block=512bytes.

Such as:

Ulimit-c 4 (note that if the size here is too small, the corresponding core file may not be generated. When the author has set ulimit-c 1, the system does not generate core file. After trying to generate core, at least 4 is needed to generate core file.)

However, the ulimit currently set is only valid for the current session. If you want the system to be valid, you need to make the following settings:

Add the following line to / etc/profile, which will allow the coredump file to be generated

Ulimit-c unlimited

Add the following line to rc.local, which will cause the coredump file generated when the program crashes to be in the / data/coredump/ directory:

Echo / data/coredump/core.%e.%p > / proc/sys/kernel/core_pattern

Note that rc.local may store different directories in different environments, and / etc/rc.d/rc.local may be used in susu.

For more commands on ulimit, please refer to: http://baike.baidu.com/view/4832100.htm

These require root permission, and each time you reopen the interrupt under ubuntu, you need to re-enter the above ulimit command to set the core size to infinite.

2. The current user, that is, the user who executes the corresponding program, has write permission to write to the core directory and has enough space.

3. Several situations in which core files will not be generated:

The core file will not be generated if

(a) the process was set-user-ID and the current user is not the owner of the program file, or

(B) the process was set-group-ID and the current user is not the group owner of the file

(C) the user does not have permission to write in the current working directory

(d) the file already exists and the user does not have permission to write to it, or

(e) the file is too big (recall the RLIMIT_CORE limit in Section 7.11). The permissions of the core file (assuming that the file doesn't already exist) are usually user-read and user-write, although Mac OS X sets only user-read.

Fifth, several possible situations of coredump

There are many reasons for program coredump. Here are some common experiences:

1. Memory access is out of bounds

A) the array access is out of bounds due to the use of the wrong subscript.

B) when searching for a string, rely on the string Terminator to determine whether the string ends, but the string does not use the Terminator properly.

C) use strcpy, strcat, sprintf, strcmp,strcasecmp and other string manipulation functions to read / write the target string. Functions such as strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp, etc., should be used to prevent reading and writing from crossing the line.

2. Multithreaded programs use thread-unsafe functions.

You should use the following reentrant functions, which can easily be misused:

Asctime_r (3c) gethostbyname_r (3n) getservbyname_r (3n) ctermid_r (3s) gethostent_r (3n) getservbyport_r (3c) ctime_r (3c) getlogin_r (3c) getservent_r (3c) fgetgrent_r (3c) getnetbyaddr_r (3n) getspent_r (3c) fgetpwent_r (3c) getnetbyname_r (3n) getspnam_r (3c) fgetspent_r (3c) getnetent_r (3n) gmtime_r (3c) gamma_r (3m) getnetgrent_r (3n) Lgamma_r (3m) getauclassent_r (3) getprotobyname_r (3n) localtime_r (3c) getauclassnam_r (3) etprotobynumber_r (3n) nis_sperror_r (3n) getauevent_r (3) getprotoent_r (3n) rand_r (3c) getauevnam_r (3) getpwent_r (3c) readdir_r (3c) getauevnum_r (3) getpwnam_r (3c) strtok_r (3c) getgrent_r (3c) getpwuid_r (3c) tmpnam_r (3s) getgrgid_r ( 3C) getrpcbyname_r (3n) ttyname_r (3c) getgrnam_r (3c) getrpcbynumber_r (3n) gethostbyaddr_r (3n) getrpcent_r (3n)

3. The data read and written by multi-thread is not protected by lock.

For global data that will be accessed by multiple threads at the same time, we should pay attention to locking protection, otherwise it is easy to cause coredump

4, illegal pointer

A) use null pointers

B) feel free to use pointer conversion. A pointer to a piece of memory that should not be converted to a pointer to this structure or type unless it is determined that the memory was previously allocated to a structure or type, or an array of that structure or type. Instead, copy the memory into one of these structures or types, and then access the structure or type. This is because if the starting address of this memory is not aligned according to this structure or type, it is easy to core dump it because of bus error when accessing it.

5, stack overflow

Do not use large local variables (because local variables are assigned on the stack), which can easily cause stack overflows, destroy the stack and heap structure of the system, and lead to inexplicable errors.

Sixth, use gdb to locate coredump.

In fact, there are many tools for analyzing coredump. Now most unix-like systems provide tools for analyzing coredump files. However, the tool we often use is gdb.

Here we take the program as an example to illustrate how to locate.

1, Segment error-segmentfault

Let's write a piece of code to write to the address protected by the system.

Z. compiles and executes as follows, and note that the-g option is required here.

As you can see, when you enter 12, the system prompts for a segment error and core dumped

Let's go to the corresponding core file generation directory, give priority to confirm whether the core file format and enable gdb for debugging.

From the screenshot of the red box, you can see that the program stops because of signal 11, and from the bt (backtrace) command (or where), you can see the call stack of the function, that is, the program executes to line 5 of coremain.cpp, and the scanf function is called inside, and the function actually calls the _ IO_vfscanf_internal () function internally.

Next, we continue to debug the corresponding program with gdb.

Remember a few commonly used gdb commands:

L (list), showing the source code, and you can see the corresponding line number

B (break) x, x is the line number, indicating that the breakpoint is set at the corresponding line number location

P (print) x, x is the name of the variable, indicating the value of the print variable x

R (run), indicating the location where execution continues to the breakpoint

N (next), which means to perform the next step

C (continue), indicating that execution continues

Q (quit), indicating exit from gdb

Start gdb and note that the program compiles with the-g option.

Note: SIGSEGV 11 Core Invalid memoryreference

7. Note:

1. View the source code of gdb

Show source code

GDB can print out the source code of the program being debugged. Of course, the-g parameter must be added when the program is compiled to compile the source program information into the execution file. Otherwise, you won't see the source program. When the program stops, GDB reports that the program stops on which line of that file. You can use the list command to print the source code of the program. Let's take a look at the GDB command for the source code.

List

Displays the source programs around the linenum line of the program.

List

Displays the source program for a function named function.

List

Displays the source program after the current line.

List-

Displays the source program in front of the current line.

Generally print the top 5 lines and the next 5 lines of the current line, if the display function is the top 2 lines and the bottom 8 lines, the default is 10 lines, of course, you can also customize the display range, use the following command to set the number of lines to display the source program at a time.

Setlistsize

Sets the number of lines to display the source code at a time.

Showlistsize

View the settings for the current listsize.

The list command is also used as follows:

List

Displays the source code from the first line to the last line.

List

Displays the source code from the current line to the last line.

List +

Show the source code later.

Generally speaking, list can be followed by the following parameters:

Line number.

The positive offset of the current line number.

The negative offset of the current line number.

Which line of which file.

Function name.

Which function in which file.

The address of the statement in memory when the program is running.

2, the meaning of some commonly used signal

SIGABRT: this signal is generated when the abort function is called. The process terminated abnormally.

SIGBUS: indicates a hardware failure defined by an implementation.

SIGEMT: indicates a hardware failure defined by an implementation. The name EMT comes from the emulator trap instruction of PDP-11.

SIGFPE: this signal indicates an arithmetic exception, such as dividing by 0, floating-point overflow, etc.

SIGILL: this signal indicates that the process has executed an illegal hardware instruction. 4.3BSD this signal is generated by the abort function. SIGABRT is now used here.

SIGIOT: this indicates a hardware failure defined by an implementation. The name IOT comes from PDP-11 's abbreviation for input / output TRAP (input/outputTRAP) instructions. In earlier versions of system V, this signal was generated by the abort function. SIGABRT is now used here.

SIGQUIT: when the user presses the exit key on the terminal (usually using Ctrl-/), this signal is generated and sent to the foreground.

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

SIGSEGV: indicates that the process made an invalid storage access. The name SEGV stands for "segmentationviolation".

SIGSYS: indicates an invalid system call. For some unknown reason, the process executed a system call instruction, but its parameter indicating the system call type is invalid.

SIGTRAP: indicates a hardware failure defined by an implementation. This signal name comes from the TRAP instruction of PDP-11.

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

3, the format of Core_pattern

There are many variables you can use in the core_pattern template, as shown in the following list:

%% single% character

% p process ID of all dump processes

% u actual user ID of the dump process

G the actual group ID of the dump process

S caused the signal of this core dump

Time of% t core dump (seconds since January 1, 1970)

% h hostname

% e program file name

The above is how to understand coredump, the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.