ROS program crashes under Linux, process has died [pid 20083, exit code -11, cmd /home GDB core dump debugging

       Under Linux, the stack information when the program exits abnormally (such as exception signals SIGSEGV, SIGABRT, etc.) can be obtained through the core file. Core dump is called a core dump . It is a memory snapshot at the moment when an exception occurs during the running of the program. When an exception occurs in the program and the exception is not captured within the process, the operating system will store the memory, register status, and Information dumps such as running stacks are saved in a core file, called core dump. The core file is a file generated by core dump after illegal execution of the program. This file is a binary file and can be opened and analyzed using gdb, elfdump, and objdump to analyze the specific contents.

Possible reasons for core dump : (1). Memory access out of bounds;

                                               (2). Multi-threaded programs use thread-unsafe functions;

                                               (3). Data read and written by multi-threads is not protected by locks;

                                               (4). Illegal pointer;

                                               (5). Stack overflow.

Debugging steps:

1. Check whether core dump is open. If it returns 0, it means it is not open. If it returns unlimited, it means it is open.

ulimit -c

2. If core dump is not turned on

ulimit -c unlimited

After executing this command, it is only valid for the current terminal.

If you want it to be valid for all terminals, add this line of code at the end of .bashrc, as follows

3. To generate an executable file, add the -g option to obtain the specific line number information, otherwise there will be no

g++ -g -o main main.c

4. After executing the program, a core file is generated. The core file is placed in the same directory as the executable file by default, and the file name is fixed to core.

./main

Execute the following command to change the file name to a form such as core.pid, where pid is the process number executing the current program, and the original content in core_uses_pid is 0: 

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

Quote 1 , Quote 2

5. Use gdb to debug core

gdb main core

6. View program stack information

bt

small test:

#include "stdio.h"
 
int main(){
	int *b = 0;
	*b = 10;
	printf("******** b = %d ************ ",*b);
}

The core file is generated

The program error is shown on line 5. 

reference

Methods to generate crash files for analysis under ros: 

1. Check whether core dump is turned on

2. Then run the node directly with roslaun or rosun, and then generate a crash file. The location where the core dump file is generated during roslaunch is under $ROS_HOME. If not configured, it defaults to the ~/.ros directory.

        Note: When compiling and generating executable files or libraries, you must turn on the debugging option, otherwise there will be no gdb debugging information, and you will not be able to view the source code and set breakpoints .

        Direct compilation of a single file: just add the -g option
g++ -g -o main main.c
        Project compilation: 

                Command line mode:

catkin_make -DCMAKE_BUILD_TYPE=Debug

                Modify the CMakelist.txt file:

SET(CMAKE_BUILD_TYPE "Debug")
SET(CMAKE_CXX_FLAGS_DEBUG "$ENV{CXXFLAGS} -O0 -Wall -g -ggdb")
SET(CMAKE_CXX_FLAGS_RELEASE "$ENV{CXXFLAGS} -O3 -Wall")

3. View the core dump file with gdb (-q: indicates a disclaimer that blocks GDB printing)

gdb main core -q

 reference

Guess you like

Origin blog.csdn.net/qq_34761779/article/details/131578480