动态链接函数dlsym()的参数RTLD_NEXT使用注意事项

相比于已知函数的所在动态库，函数dlsym的参数RTLD_NEXT可以在对函数实现所在动态库名称未知的情况下完成对库函数的替代。这提供了巨大的便利。但是凡是有一利必有一弊，在使用该参数时，需要注意一些问题。

使用的函数文件
main函数.c

#include 
#include 

int main (void) {
    struct mallinfo bfmalloc = mallinfo();
    printf("bfmalloc: %d\n",bfmalloc.uordblks);
    int *p = malloc(32);
    struct mallinfo afmalloc  = mallinfo();
    printf("afmalloc: %d\n",afmalloc.uordblks);
    free(p);
    struct mallinfo fmalloc = mallinfo();
    printf("fmalloc: %d\n",fmalloc.uordblks);
    return 0;
}

包装函数实现文件.h

void *memAlloc(size_t size);
void memFree(void *ptr);

包装实现文件.c

#ifdef RUNTIME
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include "mymalloc.h"
void *malloc(size_t size) {
    void*(*mallocp)(size_t size);
    char *error;
    mallocp = dlsym(RTLD_NEXT,"malloc");
    assert(dlerror() == NULL);
    char *ptr = mallocp(size);
    return ptr;
}
void free(void *ptr) {
    assert(ptr != NULL);
    char *error;
    void (*freep)(void *ptr);
    freep = dlsym(RTLD_NEXT,"free");
    assert(dlerror() == NULL);
    freep(ptr);
}
void *memAlloc (size_t size) {
    void *ptr = malloc(size);
    printf("ret:%d : %p\n",size,ptr);
    return ptr;
}
void memFree(void *ptr) {
    free(ptr);
    printf("free ret: %p\n",ptr);
}
#endif

我们首先编译并运行一下程序，看看运行结果
编译步骤：

gcc -DRUNTIME -shared -fPIC -o mymalloc.so mymalloc.c
gcc -o t main.c ./mymalloc.so -ldl

运行./t

我们可以很明显的看到，我们并没有释放掉我们所申请的空间，虽然我们显示的调用了内存分配函数free。那么为什么会造成内存泄露呢？简单的来说原因是因为在使用了RTLD_NEXT参数后，编译器在查询函数的实现库时，对库的访问顺序不同造成的，详细的原因大家可以参考下面这篇博文：
Dangers of using dlsym() with RTLD_NEXT

其次在使用该参数时还碰到了一个问题：不能在malloc的实现文件里面加入任何带有缓冲的输出语句，否则便或造成段错误：有兴趣的读者可以试一下。这个是加了printf语句之后，函数的调用栈

至于程序为什么会在__vfprintf_internal()子函数处宕掉，我有一个大胆的想法：

• 当加了带缓冲的输出语句：以printf为例，程序的编译是没有问题的，但是当程序运行时便会产生错误。原因是因为：printf函数首先会将格式控制串语句写入到自己的缓冲区里面，此时修改了内存中的只读文本段，所以会导致程序触发一般保护故障处理流程。那么我们如何印证这个猜想呢？可以利用stderr标准错误输出来打印我们想要输出的语句，此时你便会发现程序得以正常运行，并没有引发任何的故障。

如果有强迫症就想在malloc的实现文件中加入printf语句，那么可以像上面的memAlloc一样加一层包装函数，在该函数中可以执行替代原来库函数功能的执行逻辑。

当然了你也可以采用在编译时期或者链接时期完成对函数的 “打桩”，在此便不在赘述。

---

总而言之：尽可能的避免使用RTLD_NEXT参数，如果实在想替代动态库中某些函数的功能，一定要尽可能要了解函数定义所在的具体动态库的名称。使用动态链接器提供的函数接口，走完整的流程才是稳妥的方案。