官方参考文档：http://www.gnu.org/software/gdb/documentation/
GDB（GNU 项目调试器）可以让您了解程序在执行时“内部” 究竟在干些什么，以及在程序发生崩溃的瞬间正在做什么。 GDB 做以下 4 件主要的事情来帮助您捕获程序中的 bug：
◼ 在程序启动之前指定一些可以影响程序行为的变量或条件
◼ 在某个指定的地方或条件下暂停程序
◼ 在程序停止时检查已经发生了什么
◼ 在程序执行过程中修改程序中的变量或条件，这样就可以体验修复一个 bug 的成果，并继续了解其他 bug
准备
1、编译软件的时候 使用 gcc -g xxx.c -o xxx 使用-g参数， 表明需要生成有调试信息的可执行程序
gcc -g xxx.c -o xxx
2、在实际生成调试程序时，一般不仅要加上 -g 选项，也建议关闭编译器的程序优化选项。编译器的程序优化选项一般有五个级别，从 O0 ~ O4 （ 注意第一个 O0 ，是字母 O 加上数字 0 ）， O0 表示不优化，从 O1 ~ O4 优化级别越来越高，O4 最高。这
样做的目的是为了调试的时候，符号文件显示的调试变量等能与源代码完全对应起来 ， 默认是-O0 不优化
3、第1步骤生成的课执行程序是有调试信息的， 如果不需要调试信息 可以使用 strip + 可执行程序，去掉打印信息
strip xxx
启动gdb调试 三种方式
1、直接调试可执行文件，
gdb xxx
2、调试正在运行的进程，而又不想终止程序， gdb attch 进程id
查看进程的方式 ps -aux
gdb attch 2367 //例如进程id 为 2367
当调试完程序想结束此次调试时，而且不对当前进程有任何影响，也就是说想让这个程序继续运行，可以在 GDB 的命令行界面输入 detach 命令让程序与 GDB 调试器分离，这样 redis就可以继续运行了
(gdb) detach
3、调试core_dump 文件，gdb filename coredumpname
gdb filename core_dump123141231
调试core_dump文件主要是用在：有时候，服务器程序运行一段时间后会突然崩溃，这并不是我们希望看到的，需要解决这个问题。只要程序在崩溃的时候有 core 文件产生，就可以使用这个 core 文件来定位崩溃的原因
第1步： 查看linux是否打开了core的机制，默认linux是不打开的
ulimit -a
如果core file size 是 (blocks, -c) 0 ，则需要自己 重新设置一下 ulimite -c 的值，可以直接设置成 不做限制 ulimit -c unlimited
ulimit -c unlimited
上述操作是临时的，可以将上述命令写入到/etc/profile 中
（1）将ulimit -c unlimited 放入/etc/profile
（2）source /etc/profile
（3）再次查看 ulimit -a
第2步：设置生成core_dump文件的位置
（1）在/etc/sysctl.conf写入corefile文件生成的目录，例如
kernel.core_pattern=/home/qb/samba_myshare/seemyself/core_dump/core-%e-%p-%t
（2）创建应对的生成目录
cd /home/qb/samba_myshare/seemyself/ -- 自己设置的路径
mkdir core_dump
（3）然后执行生效 sudo sysctl -p /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf
可以查看自己是否设置成功
第3步： 写一个会core_dump的程序
#include <stdio.h> int main(void) { printf("hello world! dump core for set value to NULL pointer\n"); *(char *)0 = 0; return 0; }
编译
gcc -g -o test_core_dump test_core_dump.c
运行
./test_core_dump
在刚才我们设置生成core_dump的位置，会生成一个core_dump文件
运行gdb
gdb test_core_dump ~/samba_myshare/seemyself/core_dump/core-test_core_dump-3583-1598603271
退出gdb
q 或者 ctrl +d
常用命令
