double free or corruption错误定位

“double free or corruption”错误定位

1. 测试程序

先写一个简单的测试程序模拟double free错误：

// file: t.c

#include <stdlib.h>

void *func1(size_t size) {
    return malloc(size);
}

void func2(void *p) {
    free(p);
}

int main() {
    char *ptr = func1(sizeof(char));
    *ptr = 'a';
    func2(ptr);
    func2(ptr);
    return 0;
}

使用gcc命令进行编译：

$ gcc t.c

2. 报错信息

执行a.out可执行程序，即可得到double free的报错：

$ ./a.out
*** Error in `./a.out': double free or corruption (fasttop): 0x0000000000602010 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7c619)[0x7f127fe73619]
./a.out[0x4005af]
./a.out[0x4005e6]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f127fe18c05]
./a.out[0x4004b9]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:02 143753                             /home/chenjianfei/test/a.out
00600000-00601000 r--p 00000000 08:02 143753                             /home/chenjianfei/test/a.out
00601000-00602000 rw-p 00001000 08:02 143753                             /home/chenjianfei/test/a.out
00602000-00623000 rw-p 00000000 00:00 0                                  [heap]
7f1278000000-7f1278021000 rw-p 00000000 00:00 0
7f1278021000-7f127c000000 ---p 00000000 00:00 0
7f127fbe1000-7f127fbf6000 r-xp 00000000 08:02 657981                     /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f127fbf6000-7f127fdf5000 ---p 00015000 08:02 657981                     /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f127fdf5000-7f127fdf6000 r--p 00014000 08:02 657981                     /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f127fdf6000-7f127fdf7000 rw-p 00015000 08:02 657981                     /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f127fdf7000-7f127ffaf000 r-xp 00000000 08:02 656720                     /usr/lib64/libc-2.17.so
7f127ffaf000-7f12801af000 ---p 001b8000 08:02 656720                     /usr/lib64/libc-2.17.so
7f12801af000-7f12801b3000 r--p 001b8000 08:02 656720                     /usr/lib64/libc-2.17.so
7f12801b3000-7f12801b5000 rw-p 001bc000 08:02 656720                     /usr/lib64/libc-2.17.so
7f12801b5000-7f12801ba000 rw-p 00000000 00:00 0
7f12801ba000-7f12801db000 r-xp 00000000 08:02 656713                     /usr/lib64/ld-2.17.so
7f12803c9000-7f12803cc000 rw-p 00000000 00:00 0
7f12803d9000-7f12803db000 rw-p 00000000 00:00 0
7f12803db000-7f12803dc000 r--p 00021000 08:02 656713                     /usr/lib64/ld-2.17.so
7f12803dc000-7f12803dd000 rw-p 00022000 08:02 656713                     /usr/lib64/ld-2.17.so
7f12803dd000-7f12803de000 rw-p 00000000 00:00 0
7ffc2ac7d000-7ffc2ac9e000 rw-p 00000000 00:00 0                          [stack]
7ffc2acc9000-7ffc2accb000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted

一般都配置coredump，可以直接用gdb从core文件中找到报错的堆栈.
在没有coredump的情况下，可以通过addr2line结合上面的报错堆栈把函数调用打出来：

$ addr2line -e ./a.out 0x4005af -f
func2
??:?
$ addr2line -e ./a.out 0x4005e6 -f
main
??:?
$ addr2line -e ./a.out 0x4004b9 -f
_start
??:?

上面就是第二次free报错的堆栈，具体位置在func2中，可以检查func2的调用次数。

3. 其他定位方法

有时double free的问题并不是那么好定位，尤其是使用tcmalloc等内存管理的library时，程序free一个已经释放的空间时，并不会立即报错（这块内存并没有返回系统），只是在做真正gc或者内存重分配时，才会报错，这个错误堆栈就和double free的位置相差甚远了。
这个时候使用上面的方法就不太容易解决了。

3.1 MALLOC_CHECK_

可以通过设置MALLOC_CHECK_环境变量，实现对内存的分配和释放做一些检查：

• MALLOC_CHECK_=0：关闭所有检查；
• MALLOC_CHECK_=1：当有错误被探测到时，在标准错误输出(stderr)上打印错误信息；
• MALLOC_CHECK_=2：当有错误被探测到时，不显示错误信息,直接进行中断。

可以在gdb中设置该环境变量打印不同的调试信息，如下在free的时候增加了有效内存地址的检查：

$ gdb ./a.out
(gdb) set environment MALLOC_CHECK_ 2
(gdb) r
Starting program: /home/chenjianfei/test/./a.out

Program received signal SIGABRT, Aborted.
0x00007ffff7a4d1f7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.x86_64
(gdb) bt
#0  0x00007ffff7a4d1f7 in raise () from /lib64/libc.so.6
#1  0x00007ffff7a4e8e8 in abort () from /lib64/libc.so.6
#2  0x00007ffff7a974b9 in free_check () from /lib64/libc.so.6
#3  0x00000000004005af in func2 ()
#4  0x00000000004005e6 in main ()
(gdb)

3.2 其他方法

也可以通过mtrace来做检测，只是该方法对业务代码有侵入，需要在应用程序中设置环境变量。

另外也可以通过systap在程序中加一些探点来做，可以参照之前的文章：https://cjfeii.blog.csdn.net/article/details/51518437

4. ref

• https://stackoverflow.com/questions/2902064/how-to-track-down-a-double-free-or-corruption-error
• https://cjfeii.blog.csdn.net/article/details/51518437