Brief introduction of Coredump and Coredump reason summary

Brief introduction and Coredump reason summary of from:http://www.cnblogs.com/doctorqbw/archive/2011/12/21/2295962.html Dr. Wei Coredump

What is Coredump?

Typically, COREDMP contains memory, register status, stack pointers, memory management information, and so on when the program runs. It can be understood that the current state of the program's work is stored as a file. Many programs and operating systems automatically generate a core file when errors occur.

How do I use Coredump?

Coredump can be used on many occasions, the use of Linux, or Solaris people may have this experience, the system is running some stress test or system load a large, the system will hang or simply Panic. The only thing that can help you analyze and solve the problem is coredump.

Now a lot of coredump should appear when the program goes wrong.

Tools for analyzing Coredump

Most Unix-like operating systems now provide tools for analyzing core files, such as the GNU Binutils Binary File Descriptor Library (BFD), GNU Debugger (gdb), MDB, etc.

File formats for Coredump

The Coredump file is saved in the Unix-like operating system using the EFI format.

Under the Solairs

bash-3.2# file *unix.3 ELF 32-bit LSB executable 80386 Version 1, statically linked, not stripped, no debugging informatio n availableunix.4 ELF 32-bit LSB executable 80386 Version 1, statically linked, not stripped, no debugging information Ava Ilable

There are many reasons for the coredump of the program, and here is a summary based on previous experience:

1 memory access out of bounds
A) 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 have a normal use terminator
c) Use strcpy, strcat, sprintf, strcmp, strcasecmp and other string manipulation functions, the target string read/write burst. You should use strncpy, strlcpy, Strncat, Strlcat, snprintf, strncmp, strncasecmp, and other functions to prevent read and write out of bounds.

2 multithreaded threads use a thread-unsafe function.
The following reentrant functions should be used, with particular attention to the red-labeled functions, which are easily used incorrectly:
Asctime_r (3c) Gethostbyname_r (3n) getservbyname_r (3n) ctermid_r (3s) gethostent_r (3n) getservbyport_r (3n) Ctime_r (3c) Getlogin_r (3c) Getservent_r (3n) 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 multi-thread read-write data is not locked for protection.
For global data that can be accessed concurrently by multiple threads, you should pay attention to lock protection, otherwise it is easy to cause core dump

4 illegal pointers
A) use a null pointer
b) Feel free to use pointer conversions. A pointer to a piece of memory, unless it is determined that the memory was originally assigned to a struct or type, or to an array of this structure or type, do not convert it to a pointer of this structure or type, but should copy the memory into one such structure or type, and then access the structure or type. This is because if the start address of this memory is not aligned with this structure or type, then it is easy to access it because of the bus error and core dump.

5 Stack Overflow
Do not use large local variables (because local variables are allocated on the stack), which can easily cause a stack overflow, destroying the stack and heap structure of the system, resulting in inexplicable errors.

How to generate coredump files and how to use them:

(assuming that the following example is a cross-compilation on x86 and running an exception on arm)

1. added support for coredump in the arm kernel (general kernel supports coredump, no re-coding)

2. Run the command, allowing the coredump file to be generated at this time:(on arm )
Ulimit–c Unlimited

3. Execution procedure: (on arm)
./test
When the exception exits, the following information is displayed, noting the contents in parentheses
Segmentation fault (core dumped)
*core file will be generated under program execution directory

4. Using gdb to analyze: (on x86)
Arm-linux-gdb./test Test.core
And then use GDB's bt or where to see it.
(Arm-linux-gdb compilation < debugging tool four gdbserve>)

The system supports generating the core and setting the storage location method:

1> Add the following line to the/etc/profile, which will allow the generation of coredump files
Ulimit-c Unlimited

2> adds the following line to the rc.local, which causes the Coredump file generated when the program crashes in the/tmp directory:
echo/tmp/core.%e.%p >/proc/sys/kernel/core_pattern

/tmp/can also be a different directory location. The best locations should meet the following requirements:
* Written to all users
* Space capacity is large enough
* The file is not lost after power-down

View stack Information
—————

When the program is stopped, the first thing you need to do is to see where the program is parked. When your program calls a function, the address of the function, the function arguments, the local variables within the function are pressed into the stack. You can use the GDB command to view the information in the current stack.

Here are some GDB commands to view the function call stack information:

    backtrace 
    bt 
         Prints all the information for the current function call stack. such as:
        
        (GDB) bt
        #0   func (n=250) at Tst.c:6
         #1   0x08048524 in Main (Argc=1, argv=0xbffff674) at tst.c:30
         #2   0x400409ed in __libc_start_main () from/lib/libc.so.6
       & nbsp
        can see the function's call stack information from above: __libc_start_main-to-Main () and func ()
        
    
    backtrace <n>
    bt <n> 
        n is a positive integer, Indicates that stack information is printed only on the top N-tier of the stack.

BackTrace <-n>
BT <-n>
The-n table is a negative integer that prints only the stack information for the n-tier below the stack.

If you want to view a layer of information, you need to switch the current stack, generally speaking, when the program stops, the topmost stack is the current stack, if you want to see the stack below the details of the layer, the first thing to do is to switch the current stack.

Frame <n>
F <n>
N is an integer starting from 0, which is the layer number in the stack. For example: Frame 0, representing the top of the stack, frame 1, represents the second layer of the stack.

Up <n>
Moves the n layer to the top of the stack without hitting N, which means moving up one layer.

Down <n>
Moves the n layer below the stack, without hitting N, to move down one layer.

The above command will print out the information of the stack layer that is moved to. If you don't want it to be a message. You can use these three commands:

Select-frame <n> corresponds to the frame command.
up-silently <n> corresponds to the UP command.
down-silently <n> corresponds to the down command.

To view the information for the current stack, you can use the following GDB command:

Frame or F
This information is printed out: the stack's layer number, the current function name, the function parameter value, the file and line number where the function is located, and the statement to which the function executes.

Info frame
Info F
This command prints out more detailed information about the current stack, except that most of them are internal addresses at runtime. For example: function address, call function address, called function address, the current function is written by what program language, function parameter address and value, local variable address and so on. Such as:
(GDB) Info f
Stack level 0, frame at 0xbffff5d4:
EIP = 0x804845d in func (Tst.c:6); Saved EIP 0x8048524
Called by frame at 0xbffff60c
Source Language C.
Arglist at 0xbffff5d4, args:n=250
Locals at 0xbffff5d4, Previous frame ' s SP is 0x0
Saved Registers:
EBP at 0xbffff5d4, EIP at 0xbffff5d8

Info args
Prints out the parameter names of the current function and their values.

Info locals
Prints out all local variables and their values in the current function.

Info catch
Prints out the exception handling information in the current function.




View Source Program
—————

Show source code

GDB can print out the source code of the program being debugged, of course, when the program compiles must add-g parameters, the source program information compiled into the execution file. Otherwise you will not see the source program. When the program stops, GDB reports that the program is parked on the first line of the file. You can use the List command to print the program's source code. Let's take a look at the GDB command that looks at the source code.

List <linenum>
Displays the source program around the LineNum line of the program.

List <function>
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.

In general, the current line is printed on the top 5 rows and the next 5 lines, if the display function is 2 rows below 8 lines, the default is 10 rows, of course, you can also customize the display of the range, using the following command can be set to display the source program number of lines.

Set Listsize <count>
Sets the number of lines to display the source code at a time.

Show Listsize
View the settings for the current listsize.

The list command also has the following usage:

List <first>, <last>
Displays the source code from the first row to the last row.

List, <last>
Displays the source code from the current line to the last row.

List +
The source code is displayed later.

In general, after the list can be followed by the following parameters:

<linenum> line number.
<+offset> the positive offset of the current line number.
<-offset> the negative offset of the current line number.
<filename:linenum> which line of the file.
<function> function name.
<filename:function> which function in the file.
<*address> the address of the statement in memory when the program runs.

Search Source Code

Not only that, GDB also provides the command for source code search:

Forward-search <regexp>
Search <regexp>
Search the front.

Reverse-search <regexp>
Search all.

Where,<regexp> is the regular expression, but also the main string of the matching pattern, about the regular expression, I do not speak here, but also ask you to view the relevant information.

Specify the path to the source file

At some point, only the name of the source file is included in the Execute program that was compiled with-G, and there is no path name. GDB provides a command that lets you specify the path to the source file so that gdb can search.

Directory <dirname ... >
Dir <dirname ... >
Adds a source file path to the front of the current path. If you want to specify multiple paths, under Unix you can use ":", under windows you can use ";".
Directory
Clears all the custom source file search path information.

Show directories
Displays the defined source file search path.

Source-code Memory

You can use the Info command to see the address of the source code in memory. Info line can be followed by "row number", "Function name", "File name: line number", "File name: function name", this command will print out the specified source code at runtime memory address, such as:

(GDB) Info line Tst.c:func
Line 5 of the "tst.c" starts at address 0x8048456 <func+6> and ends at 0x804845d <func+13>.

There is also a command (disassemble) You can view the current execution of the source program machine code, this command will be the current in-memory instructions dump out. The following example shows the assembly code to view the Func function.

(GDB) Disassemble func
Dump of assembler code for function func:
0x8048450 <func>: Push%EBP
0x8048451 <func+1>: mov%esp,%ebp
0x8048453 <func+3>: Sub $0x18,%esp
0x8048456 <func+6>: Movl $0X0,0XFFFFFFFC (%EBP)
0x804845d <func+13>: Movl $0x1,0xfffffff8 (%EBP)
0x8048464 <func+20>: mov 0xfffffff8 (%EBP),%eax
0x8048467 <func+23>: CMP 0x8 (%EBP),%eax
0X804846A <func+26>: Jle 0x8048470 <func+32>
0x804846c <func+28>: jmp 0x8048480 <func+48>
0x804846e <func+30>: mov%esi,%esi
0x8048470 <func+32>: mov 0xfffffff8 (%EBP),%eax
0x8048473 <func+35>: Add%EAX,0XFFFFFFFC (%EBP)
0x8048476 <func+38>: Incl 0xfffffff8 (%EBP)
0x8048479 <func+41>: jmp 0x8048464 <func+20>
0x804847b <func+43>: NOP
0x804847c <func+44>: Lea 0x0 (%esi,1),%esi
0x8048480 <func+48>: mov 0xfffffffc (%EBP),%edx
0x8048483 <func+51>: mov%edx,%eax
0x8048485 <func+53>: jmp 0x8048487 <func+55>
0x8048487 <func+55>: mov%ebp,%esp
0x8048489 <func+57>: Pop%EBP
0x804848a <func+58>: ret
End of assembler dump.

Partly transferred from: http://blog.csdn.net/haoel/article/details/2882

Brief introduction of Coredump and Coredump reason summary