sbrk - Valgrind不报告内存泄漏

Question

我写了这个小版本的malloc（没有free）：

#include <cstdio>
#include <cstddef>
#include <unistd.h>

#define word_size sizeof(intptr_t)
#define align(n) ((n + word_size - 1) & ~(word_size - 1))

void* my_malloc(size_t size) {
    void* p = sbrk(0);
    printf("before allocation: %p\n", p);
    if (sbrk(align(size)) == (void*) -1) {
        // failed to allocate memory
        return NULL;
    }
    printf("after allocation: %p\n", sbrk(0));
    return p;
}

int main() {
    int* foo = (int*) my_malloc(1);
    *foo = 100;
    printf("after allocation outside: %p\n", sbrk(0));
}

这是代码的输出结果：

before allocation: 0x1796000
after allocation: 0x1796008
after allocation outside: 0x1796008

如您所见，由my_malloc分配的内存尚未被释放。不过当我使用以下命令通过valgrind运行它时：

valgrind --leak-check=yes ./main

我理解为：

==1592== Memcheck, a memory error detector
==1592== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1592== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1592== Command: ./main
==1592== HEAP SUMMARY:
==1592==     in use at exit: 0 bytes in 0 blocks
==1592==   total heap usage: 2 allocs, 2 frees, 73,728 bytes allocated
==1592== 
==1592== All heap blocks were freed -- no leaks are possible
==1592== 
==1592== For counts of detected and suppressed errors, rerun with: -v
==1592== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

正如您所看到的，valgrind 没有发现任何内存泄漏！我是在错误地使用 valgrind 吗，还是这是一个 bug？

- xilpex

Answer 1

第一个答案不是很准确。

对于OP的简短回答：除非您告诉Valgrind有关您的分配器的更多信息，否则Valgrind将无法检测自定义内存池中的泄漏。

长答案。

当您运行valgrind时，将运行两个可执行文件。首先是valgrind本身。这是一个小应用程序，它将读取一些命令行参数，设置一些环境变量，然后查看客户应用程序以确定其位数，然后执行适当的工具，例如memcheck-x86-freebsd。

该工具不链接任何内容。不是libc，甚至不是libc启动代码。入口点在汇编器中，创建一个新的堆栈并启动valgrind_main。由于该工具没有链接任何内容，因此必须为其自己实现所有所需或想要使用的C运行时函数。这包括编译器可能隐式生成的一些函数。例如，执行结构分配的代码可能会导致编译器生成对memcpy()的调用。这就是引用文本所指的内容。这些函数也由工具而不是libc提供。这与重定向机制无关。

关于重定向。 valgrind 将设置 LD_PRELOAD（或平台特定的版本，例如 LD_32_PRELOAD）。这将指向一个“核心”组件（例如 vgpreload_core-x86-freebsd.so）和一个工具组件，例如 vgpreload_memcheck-x86-freebsd.so。该工具执行链接加载器的工作，并将这些文件映射到内存中。在此过程中，它将读取 Elf 信息并记录任何“特殊”函数。这些函数使用复杂的名称重整系统，工具将识别出，例如，_vgr10010ZU_libcZdsoZa_malloc 是 libc 中 malloc 的替代品。这些重定向函数的地址被存储，并在客户端执行时使用。这种机制还意味着不同的工具可以重定向不同的函数。例如，memcheck 需要重定向 malloc 和 new 函数族，而 DRD 和 Helgrind 需要重定向 pthread_* 和 sema_*。

对于重定向的另一端，当它加载libc（和可执行二进制文件本身，涵盖静态链接情况）时，该工具也会看到目标函数。

重定向并不完全替换目标函数，它只是作为一个shim，允许该工具跟踪函数所请求的内容。

现在回到sbrk。Valgrind确实知道这个函数，但只知道它作为一个syscall。它将检查size参数是否来自无效的存储。与malloc不同，memcheck不会像跟踪内存一样跟踪内存。如果您使用--pages-as-heap=yes和massif，它将分析sbrk的使用情况。

如果您希望memcheck验证您的自定义分配函数，则必须执行以下两项中的一项操作。

• 使用标准名称和--soname-synonyms参数
• 使用客户端请求机制。

更新： 自2016年10月20日发布3.12.0版本以来，默认设置已更改为在测试exe中查找替换函数，文本已更新。

- Paul Floyd

Answer 2

Valgrind通过链接自己的函数来检查内存泄漏，取代了malloc、calloc、realloc和free。当Valgrind报告内存泄漏时，您可以看到这一点：

==24877== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1
==24877==    at 0x4C29EA3: malloc (vg_replace_malloc.c:309)
==24877==    by 0x4EC3AA9: strdup (in /usr/lib64/libc-2.17.so)
==24877==    by 0x40058E: main (x1.c:9)

您可以在这里看到，strdup 的 libc 版本被调用，但是 valgrind 替换了 libc malloc 而不是 libc 版本。

您正在使用 sbrk 在较低的级别上分配内存。Valgrind 不拦截该函数，因此它不会检测到泄漏。实际上，根据 valgrind 文档，它将 sbrk 列为依赖项。从第 1.1.4 节：

要找出Valgrind使用了哪些glibc符号，需要恢复链接标志-nostdlib -Wl,-no-undefined。这将导致链接失败，但会告诉您依赖了什么。我已经基本上消除了对glibc的依赖; 剩下的，我认为是相当无害的。据我所知，当前的依赖关系是：memset，memcmp，stat，system，sbrk，setjmp和longjmp。

- dbush

---

嗯，你确定吗？Valgrind能够处理静态链接的可执行文件吗？ - Eugene Sh.

我认为Valgrind是一个交叉低级指令的“沙盒”。 - Eugene Sh.

你确定吗？或许需要一个链接吗？ - xilpex

好的，这里是 - 请查看这里的第4.5节：https://www.valgrind.org/docs/manual/faq.html - 您可以为malloc定义一个“同义词”。但仍不清楚它如何与静态链接的可执行文件一起使用。 - Eugene Sh.