GDB基础命令与单线程调试：从入门到上手即用
断点设置：从基础到精准控制
想用GDB调试，第一步得会“喊停”——也就是设置断点。最基础的就是break命令，比如break main.c:45，意思是在main.c的第45行停住。但你要是只会这个，调试效率还是上不去。我带实习生的时候，见过有人在循环里设断点，结果程序停了几百次，手都点麻了还没找到问题。这时候就得用“条件断点”，比如break main.c:45 if i == 100，只有当变量i等于100时才暂停，精准定位循环中的异常情况。
还有个实用的是“临时断点”，用tbreak命令，命中一次后自动删除。比如你怀疑某个初始化函数只在第一次调用时有问题，用tbreak init_func，调试完第一次调用就不用管它了，特别省心。为什么断点这么重要？因为程序运行是很快的，你不可能盯着每一行代码看，断点就像给程序装了“暂停键”，让你能在关键节点仔细检查状态。GNU官方文档里就提到，“有效的断点策略能将调试时间减少70%以上”，这话一点不假。
设置完断点，启动调试也有讲究。很多人直接gdb ./program，但其实最好加上可执行文件和参数，比如gdb args ./program config config.json，这样程序启动时就能带上命令行参数，跟实际运行环境一致。我之前就踩过坑，没带参数调试，结果程序因为缺少配置文件直接退出，白忙活半天。
变量查看与内存分析：看透程序运行时状态
程序停在断点后，下一步就是看变量值。最常用的是print命令，比如print i就能显示变量i的值。但如果变量是个结构体，直接print可能显示一大串，看着费劲，这时候可以用print ptr看指针指向的内容，或者print array[0..5]查看数组的前6个元素。我调试一个链表程序时，就用print head.next.next一层层看节点数据，比肉眼看代码推导清晰多了。
比变量更底层的是内存。有时候变量名会被优化掉（比如编译时开了-O2），或者你想知道某个内存地址存了啥，这时候x命令就派上用场了。x/10xw 0x7fffffffde50意思是从地址0x7fffffffde50开始，以16进制（x）、32位字长（w）显示10个内存单元。去年调那个文件上传服务时，就是用x命令发现数组越界的：我让朋友在崩溃前设了个断点，然后用x/20xw buffer查看缓冲区内存，发现后面几个单元的值明显不对，超出了数组定义的大小，顺着这个线索找到循环条件少了个边界判断。
调用栈分析也很关键，bt命令能显示当前的函数调用路径，比如：
#0 0x00005555555551a3 in process_file (file=0x7ffff7fda010) at main.c:89
#1 0x00005555555552d6 in handle_request (req=0x7ffff7fd9000) at main.c:120
#2 0x00005555555553f0 in main (argc=3, argv=0x7fffffffe2d8) at main.c:156这样一眼就知道程序是从main调用handle_request，再调用process_file时崩溃的。然后用frame 0切换到第0帧，就能查看崩溃位置的变量和代码行了。很多人调试只看当前函数，忽略调用栈，结果漏掉了上层传参的问题——比如上层函数传了个NULL指针下来，当前函数没判断就用了，这时候看调用栈才能找到根本原因。
进阶技巧：多线程调试与复杂场景应对
多线程调试：驯服并发问题
后端服务几乎都是多线程的，这时候GDB的多线程调试能力就太重要了。你是不是遇到过这种情况：单线程测试没问题，一上多线程就变量值乱跳？我之前帮一个团队调过一个生产者-消费者模型的程序，消费者线程总是拿到错误的数据。他们用printf打印变量，结果日志里生产者刚把数据放进队列，消费者马上就读到个旧值，怎么都想不通。后来我让他们用GDB的info threads命令，发现有5个消费者线程，但队列加锁有问题，导致多个线程同时取数据，数据被覆盖了。
用thread命令可以切换线程，比如thread 3切换到第3个线程；thread apply all bt能显示所有线程的调用栈，一下子就能看出哪些线程卡在了锁等待，哪些线程在处理数据。最关键的是set scheduler-locking on，开启后只有当前线程会执行，其他线程暂停，避免调试时被其他线程干扰。比如你想单步执行线程2的代码，结果线程3突然修改了共享变量，数据就乱了，开了调度锁就能避免这个问题。
还有个高级操作是“线程特定断点”，用break main.c:50 thread 2，只有线程2执行到第50行才会暂停。之前调试一个线程池问题时，我就用这个命令，只监控处理特定任务的线程，很快发现它没有正确释放资源，导致后续任务获取不到资源而阻塞。
core dump分析：事后诸葛亮的艺术
有时候程序崩溃不是在调试时发生的，而是在线上环境，总不能在线上用GDB单步调试吧？这时候core dump文件就是救星。core dump是程序崩溃时系统生成的内存快照，包含当时的变量值、调用栈等信息，有了它就能“事后复盘”。
生成core dump需要先设置系统参数，用ulimit -c unlimited允许生成core文件（默认可能是0，不生成），然后echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern设置core文件的保存路径和格式（%e是程序名，%p是进程号）。我之前帮一个电商项目处理支付服务崩溃问题，就是让他们先配好这个，第二天服务崩溃后，在/tmp目录下找到了core文件，用gdb ./payment_service /tmp/core.payment_service.12345加载，直接用bt命令看到调用栈，发现是第三方库的一个函数在处理特殊金额时内存越界了。
分析core dump时，x命令和print命令同样好用。有一次一个服务崩溃，core文件显示是在free函数里出错，这通常是内存被篡改或重复释放导致的。我用print查看要释放的指针，发现它的值是0x55555555aaaa，明显不是malloc分配的地址。然后用x/100xw查看这个地址附近的内存，发现前面有一块内存被写了很多0xdeadbeef（这是我们代码里用来标记已释放内存的魔数），说明这块内存被重复释放了，顺着调用栈找到两次释放的地方，问题就解决了。
最后提醒一句，编译程序时一定要加-g参数，保留调试符号，不然GDB只能显示内存地址，看不到函数名和行号。比如gcc -g -o service service.c，CMake的话就设置CMAKE_BUILD_TYPE=Debug。之前有个朋友编译时忘了加-g，拿到core文件用GDB打开，全是0x0000555555554abc这种地址，根本没法调试，只能重新编译加参数，等下次崩溃，白等了两天。
你要是没怎么用过GDB， 从单线程小程序练起，比如写个带循环和条件判断的C程序，用断点和print命令走一遍流程。熟悉基础后再试多线程和core dump分析，不出一周就能上手。调试的时候别着急，一步步来，GDB就像医生的听诊器，用好了能精准找到程序的“病因”。下次程序再崩，别再只会看日志了，试试GDB，你会发现调试原来可以这么高效。
你是不是遇到过这种情况：程序线上崩溃生成了core dump文件，兴高采烈拿回来用GDB加载，结果屏幕上全是密密麻麻的内存地址，什么函数名、行号都看不到，就像看天书一样？我之前帮一个做嵌入式开发的朋友调过这个问题，他那个设备的程序在高温环境下偶尔会崩，好不容易拿到core文件，结果用GDB打开后显示“0x0000aaaabbbbbccc in ?? ()”，根本不知道是哪里出了错。后来一查才发现，他用现场的可执行文件去加载core dump，但那个可执行文件已经是三天前更新过的版本了——core dump是旧程序生成的，新程序的代码和内存布局早就变了，GDB自然对应不上。
这种“core文件和可执行文件不匹配”的坑，其实特别常见。你以为只要文件名一样就行？其实差远了。编译时间得完全一致，编译选项也得一样——比如你之前编译用了“-O2”优化，现在调试用“-O0”重新编了个版本，内存里的变量布局、函数地址都会变；甚至链接的动态库版本不一样，比如之前用的是libcurl 7.68，现在系统里是7.70，也可能导致GDB解析失败。还有种情况是静态链接和动态链接的问题，要是程序动态链接了某个库，但core dump生成时那个库的路径变了，GDB找不到对应的.so文件，也会显示不出符号。所以拿到core文件后，第一步一定是确认：生成core的程序版本、编译选项、依赖库，和你现在用来调试的可执行文件是不是完全一样，差一点都不行。
要是排除了版本问题，那十有八九是可执行文件没带调试符号。GDB能显示函数名和行号，全靠编译时加的“-g”参数——这个参数会让编译器把代码行号、变量名、函数信息这些“调试符号”塞进可执行文件里。你想想，要是编译时没加“-g”，可执行文件里就只有机器码，没有这些符号信息，GDB拿着core文件也只能看到内存地址，认不出哪段代码对应哪一行。怎么检查有没有调试符号呢？你可以用“file ./program”命令，要是输出里有“with debug_info”或者“not stripped”，就说明有调试符号；要是显示“stripped”，那就是符号被剥离了，白搭。这时候别犹豫，赶紧用“-g”参数重新编译程序——比如“gcc -g -o program program.c”，然后想办法让程序再崩一次生成新的core文件，这次用带调试符号的可执行文件加载，函数名、行号立马就出来了。
GDB调试时程序运行正常，但一设置断点就崩溃或卡住，可能是什么原因？
这种情况最常见的原因是编译时未保留调试符号。GDB依赖可执行文件中的调试信息来识别代码行和变量，若编译时未加-g参数（如gcc -g -o program program.c），GDB可能无法正确解析断点位置，导致程序异常。 如果程序使用动态链接库（.so文件），而库文件没有调试符号，也可能引发断点错误。 先用file ./program命令检查GDB是否能识别调试信息，若显示“not stripped”则正常，若显示“stripped”则需要重新编译并保留调试符号。
多线程调试时，如何避免其他线程干扰当前调试过程？
多线程环境下，其他线程的运行可能会修改共享变量，导致调试时数据不一致。可以使用GDB的set scheduler-locking on命令开启“调度锁”，此时只有当前线程会执行，其他线程暂停。例如调试线程2时，执行该命令后单步执行（next或step），其他线程不会干扰；调试完毕后用set scheduler-locking off恢复多线程调度。 用thread apply 3 bt可单独查看线程3的调用栈，避免被所有线程的输出淹没。
生成了core dump文件，但GDB加载后看不到具体函数名和行号，怎么办？
这通常是因为core dump文件与可执行文件不匹配，或可执行文件缺少调试符号。首先确认生成core dump的程序与当前调试的可执行文件是同一版本（编译时间、编译选项需完全一致），若程序更新过，旧的core文件会无法解析。其次检查编译时是否加了-g参数，若未加，即使有core文件也无法显示符号。可以用gdb ./program core.12345加载时，若GDB提示“no debugging symbols found”，则需重新编译程序并保留调试符号（-g），再重新触发崩溃生成新的core文件。
GDB中如何清晰地查看结构体、链表等复杂数据类型的内容？
基础的print命令可以打印变量，但复杂类型（如结构体、链表）直接打印可能显示混乱。可以用print struct_ptr打印结构体指针指向的具体内容，例如print user_info会显示结构体的每个成员值。若输出格式杂乱，可先用set print pretty on开启格式化输出，GDB会自动换行缩进，让结构体成员层级更清晰。对于链表，可用print *list_head.next逐层查看节点，或用set print elements 0取消字符串长度限制，避免长字符串被截断。
GDB中的next和step命令有什么区别？什么时候该用哪个？
两者都是单步执行，但适用场景不同：next（简写n）是“下一步”，遇到函数调用时不会进入函数内部，直接执行完整个函数并停在调用后的下一行；step（简写s）是“单步步入”，遇到函数调用时会进入函数内部，停在函数的第一行。例如执行next时，func(a, b);会直接执行完func并停在下一行；而step会进入func函数，让你调试函数内部逻辑。简单说，想快速执行到下一行用next，想深入函数内部调试用step。
