Core dump is also called core dump. When an exception occurs during the running of the program and the program exits abnormally, the operating system stores the current memory status of the program in a core file, called core dump. (In linux, if the memory is out of bounds, it will receive SIGSEGV signal, then core dump)
In the process of running the program, sometimes we will encounter errors such as Segment fault (segment fault). This seems to be more difficult, because there is no stack, trace information output. This type of error is often associated with pointer manipulation. It is often possible to locate in this way.
A possible cause of a segment fault and a core dump
1. Out of bounds memory access
a) Array access is out of bounds due to wrong indexing
b) When searching for a string, rely on the string terminator to determine whether the string ends, but the string does not use the normal terminator
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 should be used to prevent reading and writing out of bounds.
2 Multithreaded programs use thread-unsafe functions.
3 The data read and written by multiple threads is not protected by locks. For global data that will be accessed by multiple threads at the same time, you should pay attention to locking protection, otherwise it is easy to cause core dump
4 illegal pointer
a) use a null pointer
b) Feel free to use pointer conversions. A pointer to a piece of memory, unless you are sure that the memory was originally allocated as a structure or type, or an array of such a structure or type, do not convert it to a pointer to this structure or type, but instead The memory is copied into one such structure or type, and then the structure or type is accessed. 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 due to bus error when accessing it.
5 Stack overflow. Do not use large local variables (because local variables are allocated on the stack), which is easy to cause stack overflow, destroy the stack and heap structure of the system, and cause inexplicable errors.
Two configure the operating system to generate core files
First, use the ulimit command to check whether the system is configured to support the dump core function. Through ulimit -c or ulimit -a, you can view the configuration of the core file size. If it is 0, it means that the system has closed the dump core. It can be opened by ulimit -c unlimited. If a segmentation fault occurs, but there is no core dump, it is because the system prohibits the generation of core files.
Solution:
$ ulimit -c unlimited (only valid for the current shell process)
or at the end of ~/.bashrc : ulimit -c unlimited (once and for all)
# ulimit -c
0
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
Three Use gdb to view the core file
After a core dump occurs, use gdb to view the contents of the core file to locate the line in the file that caused the core dump.
gdb [exec file] [core file]
Such as: gdb ./test test.core
To use the gdb debugging method, first add the -g option when compiling gcc.
To debug the core file, under the Linux command line: gdb pname corefile.
For example, if the program name is controller_tester and the core file is core.3421, it is: gdb controller_tester core.3421.
This enters the gdb core debug mode.
Trace the location of the segmentation fault and the code function calls:
gdb>bt
In this way, you can generally see which sentence of the error code is, and you can also print out the value of the corresponding variable for further analysis.
gdb>print variable name
After that, it all depends on your own programming skills and experience, gdb has done a lot.
2. For programs with complex structures, such as template classes and complex calls, gdb finds the error location, which seems to be not enough. At this time, a more professional tool - valgrind should be used.
Valgrind is an open source tool software specially used for memory debugging and memory leak detection. The name valgrind is taken from the entrance to the Hall of Valor in Norse mythology. However, it must be admitted that it is indeed an artifact for memory call analysis under Linux. Generally, there should be no valgrind on the Linux system, and you need to download and install it yourself.
Download address: http://valgrind.org/downloads/current.html
Enter the download folder and execute them separately ( root permission is required, and must be installed according to the default path, otherwise there will be a loading error ):
./configure
make
make install
After successful installation, start the program with a command similar to the following:
valgrind --tool=memcheck --leak-check=full --track-origins=yes --leak-resolution=high --show-reachable=yes --log-file=memchecklog ./controller_test
Among them, --log-file=memchecklog refers to the recording log file named memchecklog; --tool=memcheck and --leak-check=full are used for memory detection.
Similar records can be obtained:
==23735==
==23735== Thread 1:
==23735== Invalid read of size 4
==23735== at 0x804F327: ResourceHandler<HBMessage>::~ResourceHandler() (ResourceHandler.cpp:48)
==23735== by 0x804FDBE: ConnectionManager<HBMessage>::~ConnectionManager() (ConnectionManager.cpp:74)
==23735== by 0×8057288: MainThread::~MainThread() (MainThread.cpp:73)
==23735== by 0x8077B2F: main (Main.cpp:177)
==23735== Address 0×0 is not stack’d, malloc’d or (recently) free’d
==23735==
You can see that the description is that Address 0x0 cannot be accessed, which is obviously an error.
In this way, valgrind directly gives the cause of the error and all the memory calls and release records in the program. It is very intelligent. When the cause of the error is known, it is much more efficient to find the error.
One more thing, valgrind also gives a report on the Memory Leak situation of the program, gives the corresponding situation of new-delete, and gives the location of all leak points. This is difficult to do in other tools, and it is very easy to use.