Core Dump parsing (4)

In a Linux system, a program crashes frequently during application running, and the following message is displayed: segmentation fault, because the application receives the SIGSEGV signal. This signal indicates that when the process has an invalid storage access and receives this signal, the default action is to terminate w/core. The meaning of terminating w/core is: generate a core file in the current directory of the process and copy the memory image of the process to the core file, the default name of the core file is "core" (a feature that has been used for a UNIX system for a long time ).
In fact, not only SIGSEGV signals generate coredump, but also some of the following signals generate coredump: SIGABRT (abnormal termination), sigbus (hardware failure), sigemts (hardware failure) sigfpe, sigill, sigquit, sigsys, and sigtrap.
In the stage of Program Development and debugging (especially for large-scale software development), the conventional debugging methods are often very painful in the case of abnormal program crashes: there is no meaningful information in the endless log. Fortunately, GDB provides and uses core files for debugging, which greatly facilitates debugging of such problems.

Next we will use a simple example to see how to debug a program crash caused by memory access violations through GDB. Here we will talk about the debugging of the dynamic library by the way.

/******** Mylib. h **********/
# Ifndef _ my_lib_h __
# DEFINE _ my_lib_h __

Int add (int x, int y );

# Endif/_ my_lib_h __
/******** End **********/

/******** Mylib. c **********/
# Include <stdlib. h>
# Include "mylib. H"

Int add (int x, int y)
{
Char * Pc = NULL;
* Pc = 10;

Return X + Y;
}
/******** End **********/

/******** Main. c **********/

# Include <stdio. h>
# Include <stdlib. h>

# Include "mylib. H"

Int main (void)
{
Int ret =-1;
Int A = 10, B = 20;
Ret = add (A, B );

Printf ("the result is: % d \ n", RET );

Return 0;
}
/******** End **********/

#####################################
# File name: makefile
#
#####################################

Cc = gcc
LD = gcc

ALL:
$ (CC) mylib. C-g-I.-FPIC-shared-O libmylib. So
$ (CC) Main. C-g-I.-L.-lmylib-o Test

Clean:
RM *. So Test
############# End ###############

First, store the above Code to the corresponding directories named mylib. H, mylib. C, Main. C, and makefile.

1) Compile the test code. Note: The-G option is required during compilation.
[Xxx @ YYY] $ make
GCC mylib. C-g-I.-FPIC-shared-O libmylib. So
GCC main. C-g-I.-L.-lmylib-o t

Through the LS command, we can see that the test program is generated.
[Xxx @ YYY] $ ls
Libmylib. So main. c makefile mylib. c mylib. h test

2) execute the test program
[Xxx @ YYY] $./test
./Test: Error while loading shared libraries: libmylib. So: cannot open shared object file: no such file or directory

This error indicates that the program cannot find the corresponding dynamic library file in the running stage. At this time, you need to use the environment variable LD_LIBRARY_PATH to specify the search directory of the dynamic library during runtime. Our dynamic library is in the current directory, as follows:

[Xxx @ YYY] $ export LD_LIBRARY_PATH = $ LD_LIBRARY_PATH :.

3) execute the test program again
[Leo @ localhost debug] $./test
Segmentation fault
[Leo @ localhost debug] $ ls
Libmylib. So main. c makefile mylib. c mylib. h test

4) set the Core File Size
Segmentation fault arrived on schedule, but there was no core file we 'd like to see!
The size of the core file is set to 0 by default. In other words, the core file is not generated. You can run the ulimit command to modify the size of the core file. Unlimited indicates that the size of the core file is not limited, as shown in the following figure (root permission is required to set the size of the core file ):
[Root @ YYY] # ulimit-C Unlimited
[Root @ YYY] #./test
Segmentation fault (core dumped)
[Root @ YYY] # ls
Core.2890 libmylib. So main. c makefile mylib. c mylib. h test

5) set the Core File Format and output path.
Run the following command to specify the Core File naming format and path (root permission required ):
[Root @ YYY] # echo "core _ % E _ % s">/proc/sys/kernel/core_pattern
[Root @ YYY] #./test
Segmentation fault (core dumped)
[Root @ YYY] # ls
Core.2890 core_test_11.2898 libmylib. So main. c makefile mylib. c mylib. h test

6) debugging
[Root @ YYY] # GDB test core.2890
Gnu gdb Red Hat Linux (6.5-8. fc6rh)
Copyright (c) 2006 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"... using host libthread_db library "/lib/libthread_db.so.1 ".

Core was generated by './test '.
Program terminated with signal 11, segmentation fault.
Error while mapping shared library sections:
Libmylib. So: success.
Reading symbols from/home/XXX/TST/libmylib. So... done.
Loaded symbols for libmylib. So
Reading symbols from/lib/i686/libc. so.6...... done.
Loaded symbols for/lib/i686/libc. so.6
Reading symbols from/lib/ld-linux.so.2... done.
Loaded symbols for/lib/ld-linux.so.2
#0 0x00a8969c in ?? ()
(GDB)

Type the gdb command where
(GDB) Where
#0 0x001ec44c in ?? ()
#1 0x00000000 in ?? ()

?? () This is not what we want to see. The reason is that GDB cannot correctly load the dynamic library libmylib. So we need to set the dynamic library search path of GDB here, as shown below:

(GDB) set solib-search-path.
Reading symbols from/home/XXX/test/TST/libmylib. So... done.
Loaded symbols for/home/XXX/test/TST/libmylib. So
Reading symbols from/lib/i686/libc. so.6...... done.
Loaded symbols for/lib/i686/libc. so.6
Reading symbols from/lib/ld-linux.so.2... done.
Loaded symbols for/lib/ld-linux.so.2

You can see that libmylib. So has been loaded by GDB, and type the where command again:
(GDB) Where
#0 0x001ec44c in add (x = 10, y = 20) at mylib. C: 8
#1 0x0804847c in main () at main. C: 12
(GDB)

The expected result is displayed this time. GDB clearly lists the error location: Row 8th of mylib. C. All right, go and change the code!