最近定位了在一个多线程服务器程序（OceanBase MergeServer）中，一个线程非法篡改另一个线程的内存而导致程序core掉的问题。定位这个问题历经波折，尝试了各种内存调试的方法。往往感觉就要柳暗花明了，却发现又进入了另一个死胡同。最初，应用弱小的mprotect+backtrace+libsigsegv等工具胜利定位了问题。整个定位过程遇到的问题和解决办法对于多线程内存越界问题都很典型，简略总结一下和大家分享。

景象

core是在系统集成测试过程中发现的。服务器程序MergeServer有一个50个工作线程组成的线程池，当应用8个线程的测试程序通过MergeServer读取数据时，后者偶然会core掉。用gdb查看core文件，发现core的起因是一个指针的地址非法，当过程拜访指针指向的地址时引起了段谬误（segment fault）。见下图。

产生越界的指针ptr_位于一个叫做cname_的对象中，而这个对象是一个动静数组field_columns_的第10个元素的成员。如下图。

复现问题

之后，花了2天的工夫，终于找到了重现问题的办法。重现屡次，能够察看到如下一些景象：

  1. 随着客户端并发数的加大（从8个线程到16个线程），出core的概率加大；
  2. 缩小服务器端线程池中的线程数（从50个到2个），就不能复现core了。
  3. 被篡改的那个指针，总是有一半（高4字节）被改为了0，而另一半看起来仿佛是正确的。
  4. 请看前一节，重现屡次，每次出core，都是因为field_columns_这个动静数组的第10个元素data_[9]的cname_成员的ptr_成员被篡改。这是一个不好解释的奇怪景象。
  5. 在代码中插入检查点，从field_columns_中内容最后产生到读取导致越界的这段代码序列中“埋点”，既应用二分查找法定位篡改cname_的代码地位。后果发现，程序有时core到检查点前，有时又core到检查点后。

综合以上景象，初步判断这是一个多线程程序中内存越界的问题。

应用glibc的MALLOC_CHECK_

因为是一个内存问题，思考应用一些内存调试工具来定位问题。因为OB外部对于内存块有本人的缓存，须要去除它的影响。批改OB内存分配器，让它每次都间接调用c库的malloc和free等，不做缓存。而后，能够应用glibc内置的内存块完整性检查性能。

应用这一个性，程序无需从新编译，只须要在运行的时候设置环境变量MALLOC_CHECK_（留神结尾的下划线）。每当在程序运行过程free内存给glibc时，glibc会查看其暗藏的元数据的完整性，如果发现错误就会立刻abort。用相似上面的命令行启动server程序：

export MALLOC_CHECK_=2bin/mergeserver -z 45447 -r 10.232.36.183:45401 -p45441

应用MALLOC_CHECK_当前，程序core到了不同的地位，是在调用free时，glibc查看内存块后面的校验头谬误而abort掉了。如下图。

但这个core能带给咱们想信息也很少。咱们只是找到了另外一种稍高效地重现问题的办法而已。或者最后看到的core的景象是延后浮现而已，其实“更早”的时刻内存就被毁坏掉了。

valgrind

glibc提供的MALLOC_CHECK_性能太简略了，有没有更高级点的工具不光可能报告谬误，还能剖析出问题起因来？咱们天然想到了赫赫有名的valgrind。用valgrind来查看内存问题，程序也不须要从新编译，只须要应用valgrind来启动：

nohup valgrind --error-limit=no --suppressions=suppress bin/mergeserver -z 45447 -r 10.232.36.183:45401 -p45441 >nohup.out &

默认状况下，当valgrind发现了1000中不同的谬误，或者总数超过1000万次谬误后，会进行报告谬误。加了--error-limit=no当前能够禁止这一个性。--suppressions用来屏蔽掉一些不关怀的误报的问题。通过一翻折腾，用valgrind复现不了core的问题。valgrind报出的谬误也都是一些与问题无关的误报。大略是因为valgrind运行程序大概会使程序性能慢10倍以上，这会影响多线程程序运行时的时序，导致core不能复现。此路不通。

须要C/C++ Linux高级服务器架构师学习材料后盾加群812855908（包含C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等）

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的形式检测的最大问题是，这种查看是“预先”的。在多线程的简单环境中，如果不能产生毁坏的第一工夫查看现场，往往曾经不能发现罪魁祸首的蛛丝马迹了。

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中蕴含的库函数：

 g++ -umalloc –lefence …

用strings来查看产生的程序是否真的应用了efence：

和很多工具相似，efence也通过设置环境变量来批改它运行时的行为。通常，efence在每个内存块的结尾搁置一个不可拜访的页，当程序越界拜访内存块前面的内存时，就会被检测到。如果设置EF_PROTECT_BELOW=1，则是在内存块前插入一个不可拜访的页。通常状况下，efence只检测被调配进来的内存块，一个块被调配进来后free当前会缓存下来，直到一下次调配进来才会再次被检测。而如果设置了EF_PROTECT_FREE=1，所有被free的内存都不会被再次调配进来，efence会检测这些被开释的内存是否被非法应用（这正是咱们目前狐疑的中央）。但因为不重用内存，内存可能会收缩地很厉害。

我应用下面2个标记的4种组合运行咱们的程序，遗憾的是，问题无奈复现，efence没有报错。另外，当EF_PROTECT_FREE=1时，运行一段时间后，MergeServer的虚拟内存很快收缩到140多G，导致无奈持续测试上来。又进入了一个死胡同。

终极神器mprotect + backtrace + libsigsegv

electric-fence的神奇能力实际上是应用零碎调用mprotect实现的。mprotect的原型很简略，

int mprotect(const void *addr, size_t len, int prot);

mprotect能够使得[addr,addr+len-1]这段内存变成不可读写，只读，可读写等模式，如果产生了非法拜访，程序会收到段谬误信号SIGSEGV。

但mprotect有一个很强的限度，要求addr是页对齐的，否则零碎调用返回谬误EINVAL。这个限度和操作系统内核的页管理机制相干。

如图，咱们曾经晓得这个动静数组的第10个元素会被非法越界批改。review了代码，发现从这个数组内容初始化结束当前，到应用这个数组内容这段时间，不应该再有批改操作。那么，咱们就能够在数组内容被初始化之后，立刻调用mprotect对其进行只读爱护。

尝试一

因为mprotect要求输出的内存地址页对齐，所以我批改了动静数组的实现，每次申请内存块的时候多调配一个页大小，而后取页对齐的地址为第一个元素的起始地位。

如上图，浅蓝色局部为为了对齐内存地址而做的padding。代码见下

动静数组申请的最小内存块的大小为64KB。这里，动静数组中每个元素的大小为80字节，咱们只须要从第1个元素开始爱护一个页的大小即可：

既然这个爱护区域是程序中主动插入的，须要在内存开释给零碎前回复它为可读写，否则必然会因mprotect产生段谬误。

好了，编译、重启、运行重现脚本。喜剧了。程序运行了很久都不再出core了，无奈复现问题。咱们在调配动静数组内存时，为了对齐在内存块前增加的padding导致程序运行时的内存散布和原来产生core的运行环境不同了。这可能是无奈复现的起因。要想复现，咱们不能毁坏原来的内存调配形式。

尝试二

不扭转动静数组的内存块申请形式，又要满足mprotect爱护的地址必须页对齐的要求，怎么做呢？咱们换一个思路，从第10个元素向前，找到蕴含它且离它最近的页对齐的内存地址。如下图

但这样会造成一个问题。图中浅蓝色局部本不是这个动静数组对象所领有的内存，它可能被其余任何线程的任何数据结构在应用。咱们应用这种形式爱护红色区域，会有很多无关的落入蓝色区域的批改操作导致mprotect产生段谬误。

试验了一下，果然，程序跑起来不久就在其余无关的代码处产生了段谬误。这种保护方式的代码如下：

胜利

在上一节的保护方式下，咱们因为爱护了无关内存区域，会导致程序过早产生SIGSEGV而退出。咱们是否截获信号，不让程序在非法拜访mprotect爱护区域后依然能继续执行呢？当然。咱们能够定制一个SIGSEGV段谬误信号的处理函数。在这个处理函数中，如果能打印段谬误时候的以后调用栈，就能够找到罪魁祸首了。

代码如上图。留神，解决SIGSEGV的handler函数有一些小技巧（坑很多）：

  1. SIGSEGV个别是内核解决的（page fault）。应用库libsigsegv能够简化用户空间撰写处理函数的难度。
  2. 处理函数中，不能调用任何可能再分配内存的函数，否则会引起double fault。例如，在这段处理函数中，应用open零碎调用关上文件，不能应用fopen；buff是从栈上调配的，不能从heap上申请；不能应用backtrace_symbols，它会向glibc动静申请内存，而要应用平安的backtrace_symbols_fd把backtrace间接写入文件。
  3. 最重要的，在SIGSEGV的处理函数中，咱们须要复原引起段谬误的内存块为可读写的。这样，当处理函数返回被中断的代码继续执行时，才不能再次引起段谬误。从新编译代码，运行重现脚本。查看记录了backtrace的文件sigsegv.bt，咱们看到了相熟的被篡改的指针地址（一半为0）：

这个段谬误会最终导致程序core掉，因为这个SIGSEGV信号不是由咱们应用mprotect的爱护而产生的。查看core文件，能够查到被越界的内存（即ptr_）的地址。从sigsegv.bt文件中查找，果然找到了那一次非法拜访：

应用addr2line查看下面这个调用栈中的地址，咱们终于找到了它。又通过一番代码review和验证，才总算确定了谬误起因。有一个动静new进去的对象的指针在两个有关联的线程中共享，在某种极其状况下，其中一个delete了对象之后，另一个线程又批改了这个对象。

小结

小结一下，遇到辣手的内存越界问题，能够应用上面程序一一尝试：

  1. code review剖析代码。
  2. valgrind用起来最简略，简直是傻瓜式的。能用尽量用。
  3. glibc的MALLOC_CHECK_应用起来和很简略，不须要重现编译代码。能够用来发现问题，然而其自身无奈定位问题。和magic number联合起来，能够用来定位一类内存越界的问题。
  4. 和electric-fence齐名的还有一个内存调试库叫做dmalloc。尽管在本次解决问题的过程中没有用到，这个库对于检测内存泄露等其余问题很有用。举荐大家学习一下，放到本人的工具库中。
  5. electric-fence是定位一类“野指针”拜访问题的利器，强烈推荐应用。
  6. 如果上述所有工具都帮不了你，那么只好在相熟代码逻辑的根底上，应用终极武器了。
  7. code review。通过尝试代码库中不同版本编译进去的程序复现bug，用二分法定位引入bug的最早的一次代码提交。