Question

我正在调试我已经工作了一段时间的项目，并且遇到了一些涉及free的疯狂错误。我无法上传代码，因为没有办法确切地说出问题所在（大约2500行代码分成22个文件），但我会解释我所知道的。

首先，gdb用于整个调试过程。通过调用free，错误似乎有所增加。程序退出gdb后，我从SIGABRT收到以下错误消息：

*** Error in `application': free(): invalid next size (normal): 0x08052008 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x767e2)[0xb7e467e2]
/lib/i386-linux-gnu/libc.so.6(+0x77530)[0xb7e47530]
application[0x8049aef]
application[0x804a8aa]
application[0x8048bee]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0xb7de9935]
application[0x8048a51]
======= Memory map: ========
08048000-08050000 r-xp 00000000 00:16 1571817    application
08050000-08051000 r--p 00007000 00:16 1571817    application
08051000-08052000 rw-p 00008000 00:16 1571817    application
08052000-08073000 rw-p 00000000 00:00 0          [heap]
b7d9c000-b7db7000 r-xp 00000000 08:01 1309022    /lib/i386-linux-gnu/libgcc_s.so.1
b7db7000-b7db8000 r--p 0001a000 08:01 1309022    /lib/i386-linux-gnu/libgcc_s.so.1
b7db8000-b7db9000 rw-p 0001b000 08:01 1309022    /lib/i386-linux-gnu/libgcc_s.so.1
b7dce000-b7dd0000 rw-p 00000000 00:00 0 
b7dd0000-b7f7d000 r-xp 00000000 08:01 1308997    /lib/i386-linux-gnu/libc-2.17.so
b7f7d000-b7f7f000 r--p 001ad000 08:01 1308997    /lib/i386-linux-gnu/libc-2.17.so
b7f7f000-b7f80000 rw-p 001af000 08:01 1308997    /lib/i386-linux-gnu/libc-2.17.so
b7f80000-b7f83000 rw-p 00000000 00:00 0 
b7f83000-b7fc4000 r-xp 00000000 08:01 1309045    /lib/i386-linux-gnu/libm-2.17.so
b7fc4000-b7fc5000 r--p 00040000 08:01 1309045    /lib/i386-linux-gnu/libm-2.17.so
b7fc5000-b7fc6000 rw-p 00041000 08:01 1309045    /lib/i386-linux-gnu/libm-2.17.so
b7fd9000-b7fdd000 rw-p 00000000 00:00 0 
b7fdd000-b7fde000 r-xp 00000000 00:00 0          [vdso]
b7fde000-b7ffe000 r-xp 00000000 08:01 1308973    /lib/i386-linux-gnu/ld-2.17.so
b7ffe000-b7fff000 r--p 0001f000 08:01 1308973    /lib/i386-linux-gnu/ld-2.17.so
b7fff000-b8000000 rw-p 00020000 08:01 1308973    /lib/i386-linux-gnu/ld-2.17.so
bffdf000-c0000000 rw-p 00000000 00:00 0          [stack]

它似乎像一个普通的双免费，但还有更多。当它们不包含任何内容时，我倾向于将所有全局指针设置为NULL，所以即使我双重释放它也不会导致错误。此外，当我的应用程序处理数据加密时，我创建了两个我自己的函数，首先覆盖内存然后免费调用。

这个问题是否可以通过读取超出界限的内存引起的？例如，如果我有一个64字节的内存块并意外尝试读取第65个字节，这会在调用free时导致错误吗？我知道写出界限，即使没有立即，也会导致错误......

我一直在努力找到这个bug，但没有成功。 gdb是否为我的案例提供了任何工具（除了休息，步骤，继续和观察）？我可以在内存分配和管理方面看到我的代码真正做了什么吗？例如，有没有办法看到在特定指针指向的位置实际分配了多少内存？

提前感谢您的时间！：）

Answer 1

由于覆盖了未分配的内存，这种情况有点像是内存管理损坏。

您可能希望使用Valgrind进行分析。

Answer 2

@alk已经回答了，但我将这个FYI作为另一个行为不端的自由职能的罪魁祸首：

如果指向已分配内存块的指针已移至其他位置：例如

  char *string;
  string = malloc(10);
  string++;      //move memory pointer to location other than originally allocated  
  free(string);  //attempt to free will result in error

free试图释放指针，不再指向已分配的内容，并且总是会抛出错误。

免费的特殊错误

2 个答案: