How to debug a crashed program

Original link: http://community.bwbot.org/topic/138

In the development of the program often encountered such a problem, for C or C + + programs sometimes crashes can not get effective debugging information
Segmentation fault
Core Dump
How to debug such a program.
We can use GDB to debug the crash program.

First, open the core dump file. After it is turned on, the operating system automatically stores the crash information in the core file when the program crashes.
In the terminal input

Ulimit-c Unlimited

This turns on the core dump feature.

Here is a real example of a crash

randoms@nowhere:~/ramdisk$/home/randoms/documents/ros/workspace/devel/lib/orb_slam2/mono/home/randoms/ documents/ros/workspace/src/orb_slam2/examples/ros/orb_slam2/data/orbvoc.bin/home/randoms/documents/ros/ Workspace/src/orb_slam2/examples/ros/orb_slam2/data/setting4.yaml/camera/image_raw:=/camera_node/image_raw/ Pose2d:=/xqserial_server/pose2d > Orb.log 
mono:. /nptl/pthread_mutex_lock.c:350: __pthread_mutex_lock_full:assertion ' (-(e))!= 3 | | !robust ' failed.
Aborted (core dumped)
randoms@nowhere:~/ramdisk$ ls
2.bag  core  KeyFrameTrajectory.txt  Orb.log

You can see that a core file was created after the program crashed, and the following instructions were entered at the end to start debugging

randoms@nowhere:~/ramdisk$ Gdb/home/randoms/documents/ros/workspace/devel/lib/orb_slam2/mono Core

GDB's instruction format is GDB Exe_file_path Core_file_path

Wait for load to complete

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License gplv3+: GNU GPL ve Rsion 3 or later  
GDB enters in the terminal

Bt
 
can display the stack information when the crash occurs

#0 0x00007fe6ca6ecc37 in __gi_raise (sig=sig@entry=6) at.. /nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fe6ca6f0028 in __gi_abort () on abort.c:89 #2 0x00007fe6ca6e5bf6 in _ _assert_fail_base (fmt=0x7fe6ca8363b8 "%s%s%s:%u:%s%sassertion '%s ' failed.\n%n", assertion=assertion@entry=0x7 Fe6c9bb6a25 "(-(e))!= 3 | |! Robust ", file=file@entry=0x7fe6c9bb6a08". /nptl/pthread_mutex_lock.c ", line=line@entry=350, Function=function@entry=0x7fe6c9bb6b20 <__PRETTY_FUNCTION__ .8695> "__pthread_mutex_lock_full") at assert.c:92 #3 0x00007fe6ca6e5ca2 in __gi___assert_fail (Assertion=asserti On@entry=0x7fe6c9bb6a25 "(-(e))!= 3 | |! Robust ", file=file@entry=0x7fe6c9bb6a08". /nptl/pthread_mutex_lock.c ", line=line@entry=350, Function=function@entry=0x7fe6c9bb6b20 <__PRETTY_FUNCTION__ .8695> "__pthread_mutex_lock_full") at assert.c:101 #4 0x00007fe6c9ba9ce1 in __pthread_mutex_lock_full (mutex= 0x9643740) at.. /nptl/pthread_mutex_lock.c: 0x00007fe6cb03403a #5 in __gthread_mutex_lock (__mutex=0x9643740) at/usr/include/x86_64-linux-gnu/c++/4.8/bits/ gthr-default.h:748 #6 Lock (this=0x9643740) at/usr/include/c++/4.8/mutex:134 #7 Lock (THIS=0X7FE694ED5A10) At/usr/incl ude/c++/4.8/mutex:511 #8 unique_lock (__m= ..., this=0x7fe694ed5a10)---Type <return> to continue, or Q &LT;RETURN&G T To quit---at/usr/include/c++/4.8/mutex:443 #9 orb_slam2::mappoint::isbad (this=0x96434c0) AT/HOME/RANDOMS/DOCU ments/ros/workspace/src/orb_slam2/src/mappoint.cc:272 #10 0x00007fe6cb03c957 in Orb_slam2::keyframe:: Removebadpoints (this=0xa33f510) at/home/randoms/documents/ros/workspace/src/orb_slam2/src/keyframe.cc:1155 #11 0X00007FE6CAFF8B5A in ORB_SLAM2::TRACKING::GC (this=0x711d310) at/home/randoms/documents/ros/workspace/src/orb_ slam2/src/tracking.cc:311 #12 0x00007fe6cb0baef2 in Orb_slam2::gc::run (THIS=0X7157FE0) At/home/randoms/documents/ro S/workspace/src/orb_slam2/src/gc.cc:37 #13 0x00007fe6cAd42a60 in?? () from/usr/lib/x86_64-linux-gnu/libstdc++.so.6 #14 0x00007fe6c9bac184 in Start_thread (arg=0x7fe694ed6700) at Pthrea d_create.c:312 #15 0x00007fe6ca7b037d in Clone (). /sysdeps/unix/sysv/linux/x86_64/clone. s:111
 
 So that we can locate exactly which statement crashes. It can be seen that this crash is a lock problem. Inside the mappoint.cc file.