sbrk - Valgrind 不报告内存泄漏
sbrk - Valgrind doesn't report the memory leak
我写了这个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
,或者这是一个错误?
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 版本,但调用了 malloc
的 valgrind 替换而不是 libc malloc
.
您正在使用 sbrk
在较低级别分配内存。 Valgrind 不会拦截该函数,因此它不会检测到泄漏。事实上,根据 valgrind documentation,它将 sbrk
列为依赖项。来自第 1.1.4 节:
To find out which glibc symbols are used by Valgrind, reinstate the
link flags -nostdlib -Wl,-no-undefined
. This causes linking to fail,
but will tell you what you depend on. I have mostly, but not entirely,
got rid of the glibc dependencies; what remains is, IMO, fairly
harmless. AFAIK the current dependencies are: memset
, memcmp
, stat
,
system
, sbrk
, setjmp
and longjmp
.
第一个答案不是很准确。
OP 的简短回答:Valgrind 不会检测到自定义内存池中的泄漏,除非您告诉它更多关于您的分配器的信息。
长答案。
当您 运行 valgrind
时,有两个可执行文件 运行。首先是 valgrind
本身。这是一个小型应用程序,它将读取一些命令行参数,设置一些环境变量,然后查看来宾应用程序以确定其位数,然后 execve
适当的工具,例如 memcheck-x86-freebsd
.
该工具不link 任何东西。不是 libc,甚至不是 libc 启动代码。入口点位于创建新堆栈并启动 valgrind_main
的汇编程序中。由于工具 link 什么都没有,它必须自己实现它需要或想要使用的所有 C 运行time 函数。这包括编译器可能隐式生成的一些函数。例如,执行结构分配的代码可能会导致编译器生成对 memcpy()
的调用。这就是引用的文本所指的内容。这些功能也是由工具而不是 libc 提供的。这与重定向机制无关。
那么,重定向。 valgrind
将设置 LD_PRELOAD
(或平台特定版本,例如 LD_32_PRELOAD
)。这将指向一个 'core' 组件(例如 vgpreload_core-x86-freebsd.so
和一个工具组件,例如 vgpreload_memcheck-x86-freebsd.so
。该工具完成 link 加载程序的工作,并将 mmap
将这些文件存入内存。在此过程中,它将读取 Elf
信息并记录任何“特殊”函数。这些函数使用精心设计的名称修改系统,该工具将识别出 [=23] =] 是 libc
中 malloc
的替代。这些重定向函数的地址被存储起来,将在 guest 执行时使用。这种机制也意味着不同的工具可以重定向不同的函数。例如, memcheck
需要重定向 malloc
和 new
函数族,而 DRD
和 Helgrind
需要重定向 pthread_*
和 sema_*
。
对于重定向的另一端,该工具在加载 libc 时还将看到目标函数(以及可执行二进制文件本身,它涵盖
static linking).
的情况
重定向并没有完全替换目标函数,它只是作为一个垫片,允许工具跟踪函数请求的内容。
现在回到 sbrk
。 Valgrind 确实知道这一点,但只是作为系统调用。它将检查 size
参数是否来自无效存储。 memcheck
不会像 malloc
那样跟踪内存。如果您将 massif
与 --pages-as-heap=yes
一起使用,那么它将分析 sbrk
用法。
如果您希望 memcheck
验证您的自定义分配函数,那么您必须执行以下两项操作之一。
- 使用标准名称和
--soname-synonyms
参数
- Use the client request mechanism.
更新:
默认值 [自版本 3.12.0(2016 年 10 月 20 日)] 已更改为查找
测试 exe 中的替换函数,文本已更新。
我写了这个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
,或者这是一个错误?
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 版本,但调用了 malloc
的 valgrind 替换而不是 libc malloc
.
您正在使用 sbrk
在较低级别分配内存。 Valgrind 不会拦截该函数,因此它不会检测到泄漏。事实上,根据 valgrind documentation,它将 sbrk
列为依赖项。来自第 1.1.4 节:
To find out which glibc symbols are used by Valgrind, reinstate the link flags
-nostdlib -Wl,-no-undefined
. This causes linking to fail, but will tell you what you depend on. I have mostly, but not entirely, got rid of the glibc dependencies; what remains is, IMO, fairly harmless. AFAIK the current dependencies are:memset
,memcmp
,stat
,system
,sbrk
,setjmp
andlongjmp
.
第一个答案不是很准确。
OP 的简短回答:Valgrind 不会检测到自定义内存池中的泄漏,除非您告诉它更多关于您的分配器的信息。
长答案。
当您 运行 valgrind
时,有两个可执行文件 运行。首先是 valgrind
本身。这是一个小型应用程序,它将读取一些命令行参数,设置一些环境变量,然后查看来宾应用程序以确定其位数,然后 execve
适当的工具,例如 memcheck-x86-freebsd
.
该工具不link 任何东西。不是 libc,甚至不是 libc 启动代码。入口点位于创建新堆栈并启动 valgrind_main
的汇编程序中。由于工具 link 什么都没有,它必须自己实现它需要或想要使用的所有 C 运行time 函数。这包括编译器可能隐式生成的一些函数。例如,执行结构分配的代码可能会导致编译器生成对 memcpy()
的调用。这就是引用的文本所指的内容。这些功能也是由工具而不是 libc 提供的。这与重定向机制无关。
那么,重定向。 valgrind
将设置 LD_PRELOAD
(或平台特定版本,例如 LD_32_PRELOAD
)。这将指向一个 'core' 组件(例如 vgpreload_core-x86-freebsd.so
和一个工具组件,例如 vgpreload_memcheck-x86-freebsd.so
。该工具完成 link 加载程序的工作,并将 mmap
将这些文件存入内存。在此过程中,它将读取 Elf
信息并记录任何“特殊”函数。这些函数使用精心设计的名称修改系统,该工具将识别出 [=23] =] 是 libc
中 malloc
的替代。这些重定向函数的地址被存储起来,将在 guest 执行时使用。这种机制也意味着不同的工具可以重定向不同的函数。例如, memcheck
需要重定向 malloc
和 new
函数族,而 DRD
和 Helgrind
需要重定向 pthread_*
和 sema_*
。
对于重定向的另一端,该工具在加载 libc 时还将看到目标函数(以及可执行二进制文件本身,它涵盖 static linking).
的情况重定向并没有完全替换目标函数,它只是作为一个垫片,允许工具跟踪函数请求的内容。
现在回到 sbrk
。 Valgrind 确实知道这一点,但只是作为系统调用。它将检查 size
参数是否来自无效存储。 memcheck
不会像 malloc
那样跟踪内存。如果您将 massif
与 --pages-as-heap=yes
一起使用,那么它将分析 sbrk
用法。
如果您希望 memcheck
验证您的自定义分配函数,那么您必须执行以下两项操作之一。
- 使用标准名称和
--soname-synonyms
参数 - Use the client request mechanism.
更新: 默认值 [自版本 3.12.0(2016 年 10 月 20 日)] 已更改为查找 测试 exe 中的替换函数,文本已更新。