第1章：越界的「第一现场」：数组越界读写——经典案例与调试技巧

大家好，我是你们的老朋友。

做C/C++开发这么多年，要说哪个bug最让人头疼，数组越界绝对排前三。它不像空指针那样直接崩给你看，也不像死循环那样CPU飙到100%让你立刻察觉。数组越界，很多时候是「悄悄作案」——程序跑着跑着，某天突然出个诡异的结果，或者客户现场复现了，你本地却死活重现不了。

嗯，这种问题，我年轻时没少被折磨。

1.1 数组越界：到底「越」了什么？

先问个问题：数组越界，到底越的是什么？

说白了，你申请了一块连续的内存，比如 int arr[5]，系统给了你5个int的位置。你拿着下标0到4去访问，没问题。但如果你用了下标5、6甚至负数，那就是越界了。

越界本身不是语法错误——C/C++编译器不会报错。它是个运行时行为未定义的问题。什么叫未定义？就是什么都有可能发生：

• 可能读到别人的数据
• 可能改写了别的变量的值
• 可能直接段错误崩溃
• 也可能……一切正常，直到你发布上线

1.2 经典案例：一个越界引发的「血案」

我记得有一次，帮一个团队排查线上服务随机崩溃的问题。代码逻辑很简单，就是处理一个缓冲区：

#include <stdio.h>
#include <string.h>

void process_data(const char *input) {
    char buffer[64];
    // 危险！没有检查输入长度
    strcpy(buffer, input);
    printf("Buffer: %s\n", buffer);
}

int main() {
    // 模拟一个刚好超过64字节的输入
    char data[80];
    memset(data, 'A', 79);
    data[79] = '\0';
    process_data(data);
    return 0;
}

你看，strcpy 不会检查目标缓冲区大小。如果输入是79个字符，它会把79个'A'全部复制进去，然后继续往后面写。buffer只有64字节，后面的15个'A'写到了哪里？

写到了栈上紧挨着buffer的其他局部变量，甚至可能写到了函数的返回地址。

我当时排查这个bug时，用了GDB的watch命令，监视buffer后面那个变量的值。结果发现，每次调用process_data后，那个变量的值就变了。嗯，越界无疑。

1.3 调试技巧：如何抓住越界的「第一现场」？

越界bug最难的地方在于：错误发生的地方和症状暴露的地方，往往不在同一处。你看到变量A的值莫名其妙变了，但真正写坏它的是数组B的越界操作。

我个人习惯用下面几个方法，能大大提高定位效率：

技巧一：AddressSanitizer（ASan）—— 越界克星

这是我最推荐的工具，没有之一。编译时加上 -fsanitize=address，运行时一旦发生越界，它会立刻报错并打印调用栈。

// 编译
gcc -fsanitize=address -g -o test test.c

// 运行
./test

// 输出示例
==12345==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd...
WRITE of size 1 at 0x7ffd... thread T0
    #0 0x... in process_data test.c:8
    #1 0x... in main test.c:16

看到没？它直接告诉你：第8行，写越界了。这就是第一现场。

技巧二：Canary（栈保护）—— 简单有效的哨兵

GCC的 -fstack-protector 选项会在栈上放一个「金丝雀值」。如果函数返回时发现这个值被改了，说明发生了栈溢出，程序会立即终止。

// 编译时开启
gcc -fstack-protector -o test test.c

它不能告诉你哪里越界了，但能阻止越界造成更严重的后果。我曾经在一个嵌入式项目里，全靠这个选项保住了现场，不然崩溃日志都拿不到。

技巧三：手动加「哨兵变量」

有时候环境限制，不能用ASan（比如某些嵌入式平台）。我的土办法是：在数组前后各放一个固定值的变量，然后定期检查它们有没有被改写。

#include <stdint.h>

void test() {
    uint32_t guard_before = 0xDEADBEEF;
    char buffer[64];
    uint32_t guard_after = 0xDEADBEEF;

    // ... 操作buffer ...

    if (guard_before != 0xDEADBEEF || guard_after != 0xDEADBEEF) {
        printf("越界检测：哨兵被改写！\n");
        // 这里可以打印调用栈或者进入调试器
    }
}

这个方法虽然笨，但胜在零依赖。我在一个没有标准库的RTOS上就这么干过，效果还不错。

1.4 避坑指南：我曾经踩过的那些坑

讲几个我亲身经历的例子，希望能帮你少走弯路：

• 我曾经在写网络协议解析时，忘了检查报文长度。结果一个畸形包直接让整个路由器进程崩溃。后来我养成了习惯：所有外部输入，先校验长度，再拷贝。
• 我曾经在优化性能时，把 std::vector 换成了原生数组。结果一个下标计算错误，导致数据错乱，查了整整两天。现在我的原则是：能用标准容器就用标准容器，除非你能100%证明性能瓶颈在这里。
• 我曾经以为 memcpy 和 memmove 差不多，结果源地址和目标地址重叠时，memcpy 的行为是未定义的。嗯，那次数据全乱了。

1.5 本章知识体系

下面这张图，是我对数组越界问题的整体理解框架。你可以把它当作一个检查清单：

1.6 小结

数组越界，说白了就是「你以为你在自己的地盘，其实你已经踩到别人家了」。C/C++给了你极大的自由，但也要求你承担相应的责任。

这一章我们讲了越界的本质、一个经典案例、三个调试技巧，以及我个人的一些踩坑经历。记住：越界的第一现场，往往藏在看似正常的代码里。用好ASan，养成边界检查的习惯，能帮你省下大把的调试时间。