linux下定位多线程内存越界问题实践总结( 二 ) 最近定位了在一个多线程服务

magic number既然MALLOC_CHECK_可以检测到程序的内存问题，我们其实想知道的是谁（哪段代码）越了界。此时，我们想到了使用magic number填充来标示数据结构的方法。如果我们在被越界的内存中看到了某个magic number ，就知道是哪段代码的问题了。
首先，修改对于malloc的封装函数，把返回给用户的内存块填充为特殊的值（这里为0xEF），并且在开始和结束部分各多申请24字节，也填充为特殊值（起始0xBA ，结尾0xDC）。另外，我们把预留内存块头部的第二个8字节用来存储当前线程的ID ，这样一旦观察到被越界，我们可以据此判定是哪个线程越的界。代码示例如下。
文章插图
然后，在用户程序通过我们的free入口释放内存时，对我们填充到边界的magic number进行检查。同时调用mprobe强制glibc对内存块进行完整性检查。
文章插图
最后，给程序中所有被怀疑的关键数据结构加上magic number ，以便在调试器中检查内存时能识别出来。例如
文章插图
好了，都加好了。用MALLOC_CHECK_的方式重新运行。程序如我们所愿又core掉了，检查被越界位置的内存：
文章插图
如上图，红色部分是我们自己填充的越界检查头部，可以看到它没有被破坏。其中第二行存储的线程号经过确认确实等于我们当前线程的线程号。
蓝色部分为前一个动态内存分配的结尾，也是完整的（24个字节0xdc）。 0x44afb60和0x44afb68两行所示的内存为glibc malloc存储自身元数据的地方，程序core掉的原因是它检查这两行内容的完整性时发现了错误。由此推断，被非法篡改的内容小于16个字节。仔细观察这16字节的内容，我们没有看到熟悉的magic number ，也就无法推知有bug的代码是哪块。这和我们最初发现的core的现象相互印证，很可能被非法修改的内容仅为4个字节（int32_t大小）。
另外，虽然我们加宽了检查边界，程序还是会core到glibc malloc的元数据处，而不是我们添加的边界里。而且，我们总可以观察到前一块内存（图中蓝色所示）的结尾时完整的，没被破坏。这说明，这不是简单的内存访问超出边界导致的越界。我们可以大胆的做一下猜测：要么是一块已经释放的内存被非法重用了；要么这是通过野指针“空投”过来的一次内存修改。
如果我们的猜测是正确的，那么我们用这种添加内存边界的方式检查内存问题的方法几乎必然是无效的。
打怪利器electric-fence至此，我们知道某个时间段内某个变量的内存被其他线程非法修改了，但是却无法定位到是哪个线程哪段代码。这就好比你明明知道未来某个时间段在某个地点会发生凶案，却没办法看到凶手。无比郁闷。
有没有办法能检测到一个内存地址被非法写入呢？有。又一个大名鼎鼎的内存调试库electric-fence（简称efence）就华丽登场了。
使用MALLOC_CHECK_或者magic number的方式检测的最大问题是，这种检查是“事后”的。在多线程的复杂环境中，如果不能发生破坏的第一时间检查现场，往往已经不能发现罪魁祸首的蛛丝马迹了。
【linux下定位多线程内存越界问题实践总结】electric-fence利用底层硬件（CPU提供的虚拟内存管理）提供的机制，对内存区域进行保护。实际上它就是使用了下一节我们要自己编码使用的mprotect系统调用。当被保护的内存被修改时，程序会立即core掉，通过检查core文件的backtrace ，就容易定位到问题代码。
这个库的版本有点混乱，容易弄错。搜索和下载这个库时，我才发现， electric-fence的作者也是大名鼎鼎的busybox的作者，牛人一枚。但是，这个版本在linux上编译连接到我的程序的时候会报WARNING ，而且后面执行的时候也会出错。后来，找到了debian提供的一个更高版本的库，估计是社区针对linux做了改进。
使用efence需要重新编译程序。 efence编译后提供了一个静态库libefence.a ，它包含了能够替代glibc的malloc, free等库函数的一组实现。编译时需要一些技巧。首先，要把-lefence放到编译命令行其他库之前；其次，用-umalloc强制g++从libefence中查找malloc等本来在glibc中包含的库函数：