本文介绍了dlopen/dlsym/dlclose(dlfcn.h)导致内存泄漏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!
问题描述
像这样使用dlfcn系列时:
When using the dlfcn family like so:
#include <stdio.h>
#include <dlfcn.h>
typedef int(*timefunc_t)(void*);
int main()
{
timefunc_t fun;
void* handle;
handle = dlopen("libc.so.6", RTLD_LAZY);
fun = (timefunc_t)dlsym(handle, "time");
printf("time=%d\n", fun(NULL));
dlclose(handle);
return 0;
}
它会导致内存泄漏:
==28803== Memcheck, a memory error detector
==28803== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==28803== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==28803== Command: ./dl
==28803==
time=1309249569
==28803==
==28803== HEAP SUMMARY:
==28803== in use at exit: 20 bytes in 1 blocks
==28803== total heap usage: 1 allocs, 0 frees, 20 bytes allocated
==28803==
==28803== LEAK SUMMARY:
==28803== definitely lost: 0 bytes in 0 blocks
==28803== indirectly lost: 0 bytes in 0 blocks
==28803== possibly lost: 0 bytes in 0 blocks
==28803== still reachable: 20 bytes in 1 blocks
==28803== suppressed: 0 bytes in 0 blocks
==28803== Rerun with --leak-check=full to see details of leaked memory
==28803==
==28803== For counts of detected and suppressed errors, rerun with: -v
==28803== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6)
我的问题是,这是编程错误,还是dlfcn/libdl.so中的错误?
My question is, Is this a programming error, or rather a bug in dlfcn/libdl.so?
推荐答案
类似于后者.但是,这似乎没什么大不了的,因为如果重复调用dlopen/dlsym/dlclose另一个例程,您会发现内存泄漏的大小相同,并且不会随dlopen/dlclose调用的次数而增加.
Looks like the latter. However this does not appear to be a big deal because if you repeat the dlopen/dlsym/dlclose calling another routine you'll see that the memory leak is of the same size, it does not grow with the number of dlopen/dlclose calls.
这篇关于dlopen/dlsym/dlclose(dlfcn.h)导致内存泄漏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!