指针调试：从抓狂到从容
说实话，指针出问题的时候，是C程序员最想砸键盘的时刻。我见过太多同事对着屏幕发呆，就为了找一个野指针。我自己也经历过——凌晨两点，一个段错误，整个系统崩了，日志里只有一行"Segmentation fault"。嗯，那种感觉，就像你明明锁了门，回来发现窗户开着。
但后来我学会了两个武器：GDB 和 Valgrind。今天我就把这两把刷子的用法，掰开了揉碎了讲给你听。
GDB：指针的X光机
GDB 是什么？说白了就是一个让你能"钻进"程序内部看变量的工具。普通调试你只能看printf打印出来的东西，但GDB能让你直接看内存地址里的内容。
启动GDB的基本姿势
我个人习惯这样编译调试版本：
gcc -g -o my_program my_program.c
gdb ./my_program那个 -g 选项是关键，它会把源代码信息编译进可执行文件。没有它，GDB就只能看到一堆汇编，你想想看那得多痛苦。
查看指针的值和指向的内容
假设你有这么一段代码：
int a = 42;
int *p = &a;在GDB里，你可以这样玩：
(gdb) print p
$1 = (int *) 0x7fffffffe4a0
(gdb) print *p
$2 = 42
(gdb) print &p
$3 = (int **) 0x7fffffffe4a8看到了吗？print p 显示指针本身的值（地址），print *p 显示它指向的内容。这就像你拿着一个快递单号，查到了包裹在哪，又打开了包裹看里面是什么。
display *p 可以让GDB每次停下来时自动显示这个指针指向的内容。省得你一遍遍敲print。
跟踪指针的"前世今生"
我在项目中遇到过最头疼的问题，是一个指针被莫名其妙地改写了。这时候我会用 watch 命令：
(gdb) watch *p
Hardware watchpoint 1: *p
(gdb) continue只要 *p 的值发生变化，GDB就会立刻停下来，告诉你是在哪一行代码改的。这招抓"隐形凶手"特别好使。
检查链表是否完整
链表指针断裂是家常便饭。我一般这样检查：
(gdb) print head
$1 = (Node *) 0x5555555592a0
(gdb) print head->next
$2 = (Node *) 0x5555555592c0
(gdb) print head->next->next
$3 = (Node *) 0x0 // 哦，到这里结束了如果中间出现一个 0x0 但你不希望它出现，那问题就找到了。我曾经用这个方法，五分钟就定位了一个同事调了两天的bug——他忘了给新节点分配内存。
Cannot access memory at address 0x...，说明这个指针指向的内存已经释放了。这就是经典的"悬空指针"问题。
Valgrind：内存问题的侦探
GDB 是主动调试，Valgrind 则是被动检测。你正常跑程序，它在后台帮你盯着每一块内存的申请和释放。
基本用法
valgrind --leak-check=full ./my_program就这么一行，Valgrind 会跑你的程序，然后给你一份内存报告。我第一次用的时候，发现自己的"干净"程序居然漏了3处内存没释放，脸都红了。
常见问题解读
| Valgrind 输出 | 含义 | 我的经验 |
|---|---|---|
Invalid read/write of size 4 |
访问了不该访问的内存 | 通常是数组越界或野指针 |
definitely lost: 40 bytes |
内存泄漏，没释放 | malloc了但忘了free |
Conditional jump depends on uninitialized value |
使用了未初始化的变量 | 这个最隐蔽，我栽过好几次 |
实战：用Valgrind抓野指针
来看一个经典错误：
int *p = malloc(sizeof(int));
free(p);
*p = 10; // 野指针！Valgrind 会告诉你：
==12345== Invalid write of size 4
==12345== at 0x4005E8: main (test.c:5)
==12345== Address 0x51fc040 is 0 bytes inside a block of size 4 free'd
==12345== at 0x4C2FD5F: free (vg_replace_malloc.c:530)看到没？它连你是在哪一行free的、哪一行又去写的，都给你标得清清楚楚。我曾经靠这个，帮一个同事找到了他隐藏了三个月的bug——他在一个循环里free了指针，但另一个分支又去用了它。
核心原则： 每次写完指针相关的代码，先跑一遍Valgrind。不要等到出段错误了再查。我现在的习惯是，每写一个函数就测一次，绝不攒到最后一锅端。
知识体系总览
下面这张图，是我自己总结的指针调试知识结构。你可以把它当成一张地图，遇到问题就知道该往哪个方向走。
避坑指南：我踩过的那些坑
- 不要相信"看起来没问题"的指针。 我曾经有一个指针，打印出来地址是对的，但一访问就崩。后来发现是指针指向的内存被另一个线程释放了。多线程环境下，GDB的
info threads命令是你的好朋友。 - Valgrind 不是万能的。 它只能检测你实际访问到的内存问题。如果你有一个数组越界，但越界的那块内存恰好是合法的（比如栈上的其他变量），Valgrind 可能不会报错。这时候还是要靠GDB手动检查。
- 调试版本和发布版本要分开。 我见过有人用
-O2编译的程序去调试，结果GDB显示的变量值和实际对不上。优化器会把代码重排，你看到的"第10行"可能根本不是实际执行的那一行。调试时请用-O0 -g。
valgrind ./program 跑一遍，修掉所有报错。如果还有段错误，再用GDB attach上去，设断点一步步跟。这样下来，90%的指针问题都能在半小时内解决。
好了，指针调试这块，说白了就是两件事：用GDB看清楚指针在干什么，用Valgrind检查内存有没有被乱搞。这两个工具用熟了，指针就不再是噩梦，而是你手里最锋利的刀。