Linux C/C++调试之一:利用LD_PRELOAD机制监控程序IO操作

本文介绍了一种利用LD_PRELOAD机制监控程序中read/write函数调用并进行计时的方法。通过包装这些函数并在运行时替换C标准库中的实现,可以有效监控IO操作。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

#引言
有时,我们为了分析程序的某些问题(例如性能问题),需要对程序的IO操作的频率耗时等数据进行监控。就以经常调用的read和write函数为例,如何监控程序中所有上述两种操作,同时进行计时呢?使用gdb打断点自然是个方法,这样可以很容易发现程序中所有的调用,但是这样就没办法计时了。如果在程序中所有read/write函数前后打上时间戳,就可以实现计时了,但是这会有另一个问题,我们可能调用了某些三方库的接口,可能没办法为三方库的read/write函数打时间戳计时。那么有没有办法既能监控所有read/write函数调用,同时进行计时呢?自然是有的,例如本文下面要讲的——利用LD_PRELOAD机制实现上述目标。
关于LD_PRELOAD的概述,在之前一篇博文我已经进行过描述:CSAPP第三版运行时打桩Segmentation fault。这里贴上其部分内容:

CSAPP第三版7.13.3节提到了运行时打桩机制,它可以在运行时将程序中对共享库函数的调用进行截获,替换为执行自己的代码。这个机制基于动态链接器的LD_PRELOAD环境变量。如果LD_PRELOAD环境变量被设置为一个共享路径名的列表(以空格或分号分隔),那么当加载和执行一个程序,需要解析未定义的引用时,动态链接器(ld-linux.so)会先搜索LD_PRELOAD库,然后才搜索任何其他的库。有了这个机制,当加载和执行任意可执行文件时,可以对共享库中的任何函数打桩,包括libc.so

我们要做的就是对C标准库的read/write函数进行包装,实现计时功能。同时在运行时利用LD_PRELOAD将C标准库的read/write函数替换成我们的实现。
#包装read/write函数
直接上代码:

#ifndef _GNU_SOURCE
# define _GNU_SOURCE
#endif

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <unistd.h>
#include <sys/time.h>

// 计时函数,返回值是一个毫秒值
static double getMs()
{
    struct timeval tv;
    gettimeofday(&tv, NULL);
    return tv.tv_sec * 1000 + tv.tv_usec * 0.001;
}

ssize_t read(int fd, void *buf, size_t count)
{
    // 为什么要有print_times这个变量,请查看上面我贴出来的那篇博文
    static __thread int print_times = 0;
    print_times++;
    // 用于保存真正的read函数
    ssize_t (*readp)(int, void *, size_t);
    char *error;
    // 获取真正的read函数
    readp = dlsym(RTLD_NEXT, "read");
    if ((error = dlerror()) != NULL)
    {
        fputs(error, stderr);
        exit(1);
    }
    
    double start = getMs();
    // 调用真正的read函数
    ssize_t result = readp(fd, buf, count);
    double stop = getMs();

    if (print_times == 1)
    {
        // 输出调用read时的实参和耗时
        printf("read(%d, %p, %lu) %lf\n", fd, buf, count, stop - start);
    }
    print_times--;
    return result;
}

ssize_t write(int fd, const void *buf, size_t count)
{
    static __thread int print_times = 0;
    print_times++;

    ssize_t (*writep)(int, const void *, size_t);
    char *error;

    writep = dlsym(RTLD_NEXT, "write");
    if ((error = dlerror()) != NULL)
    {
        fputs(error, stderr);
        exit(1);
    }
    
    double start = getMs();
    ssize_t result = writep(fd, buf, count);
    double stop = getMs();

    if (print_times == 1)
    {
        printf("write(%d, %p, %lu) %lf\n", fd, buf, count, stop - start);
    }
    print_times--;
    return result;
}

上面的代码即能够对read/write函数进行计时,并将计时结果输出到标准输出。
将上面的代码编译成库:

$ gcc -shared -fpic -Wall -Wextra -o libwrapper.so wrapper.c -ldl

这样,我们就得到了一个libwrapper.so文件。
#替换read/write函数
用于测试的demo代码如下:

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

int main()
{
    int fd = open("test.txt", O_RDWR | O_CREAT | O_TRUNC, 0666);
    if (fd == -1)
    {
        exit(1);
    }

    write(fd, "test", 4);
    lseek(fd, 0, SEEK_SET);
    char buf[5] = {0};
    read(fd, buf, 4);
    close(fd);

    printf("%s\n", buf);
    return 0;
}

编译成可执行文件:

$ g++ main.c

那么如何使用前面生成的libwrapper.so文件呢?就像下面这样:

$ LD_PRELOAD=./libwrapper.so ./a.out

其输出为:

write(3, 0x55a5dd6c29ad, 4) 0.023926
read(3, 0x7ffcf0a92fa3, 4) 0.010010
test

这样,我们就达到了监控read/write函数的目标,对于其他IO库函数,你也可以根据需要进行包装替换。

<think>好的,用户现在遇到了关于LD_PRELOAD环境变量的问题,之前他们按照我的建议检查了配置,结果在.bashrc文件中发现了设置LD_PRELOAD为/usr/lib/x86_64-linux-gnu/libGLEW.so。现在需要解决这个错误。 首先,我需要确认用户之前的操作。用户执行了grep命令来查找LD_PRELOAD的设置,结果发现在.bashrc文件中有一行导出了这个变量,指向了libGLEW.so。但之前的错误提示是无法预加载这个库,说明路径可能有问题或者库不存在。 接下来,我需要考虑用户可能的场景。他们可能在配置MuJoCo或者相关的强化学习环境,比如Gym,这些工具依赖OpenGL,所以需要GLEW库。用户可能按照某些教程或文档设置了LD_PRELOAD,但路径不正确,或者库没有正确安装。 现在用户的问题是如何修复这个错误。根据之前提供的解决方案,用户需要注释掉错误的LD_PRELOAD设置,并确保GLEW库正确安装。用户可能已经安装了libglew-dev,但需要验证库文件是否存在,例如检查/usr/lib/x86_64-linux-gnu/下是否有libGLEW.so的相关文件。 另外,用户可能不清楚如何编辑.bashrc文件,或者担心修改后会影响其他配置。需要给出明确的步骤,比如使用nano或vim打开文件,找到对应的行并注释掉,然后保存并重新加载配置。同时,用户可能需要确认是否还有其他地方设置了LD_PRELOAD,比如在.profile或者/etc/environment中,但根据grep的结果,只有.bashrc中有这个设置。 另外,用户可能担心修改环境变量后是否需要重启终端或者重新登录,但应该知道使用source ~/.bashrc就可以立即生效。不过,如果错误仍然存在,可能需要检查其他配置文件或者是否有其他进程在设置LD_PRELOAD。 最后,用户可能希望彻底解决这个问题,避免以后再次出现。可能需要建议他们检查安装MuJoCo时的步骤,确保没有遗留的配置错误,或者推荐使用更新的MuJoCo版本,因为新版本可能不再依赖GLEW,改用其他库如GLFW。 总结下来,回答需要分步骤指导用户如何注释掉错误的配置,验证安装,并确保环境变量正确。同时要解释为什么需要这样做,以及如何预防类似问题。还要注意用户的潜在疑问,比如修改后的影响,是否需要其他操作,以及如何测试是否修复成功。</think>$\boxed{1. \text{问题定位}}$ 根据你的终端输出,**问题根源明确**:在 `~/.bashrc` 中有一行错误的环境变量配置: ```bash export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so ``` 这个配置试图强制预加载 `libGLEW.so`,但系统实际路径中可能不存在该文件(或文件名不匹配)。 --- $\boxed{2. \text{解决步骤}}$ **步骤 1:注释错误配置** 用文本编辑器(如 `nano` 或 `vim`)打开 `~/.bashrc`: ```bash nano ~/.bashrc ``` 找到 `export LD_PRELOAD=...` 这一行,在行首添加 `#` 注释符: ```bash # export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so ``` 保存退出(`Ctrl+O` → `Enter` → `Ctrl+X`)。 **步骤 2:使配置生效** 立即刷新环境变量: ```bash source ~/.bashrc ``` 此时错误应消失。 --- $\boxed{3. \text{验证修复}}$ 重新检查 `LD_PRELOAD` 是否清除: ```bash echo $LD_PRELOAD ``` 若输出为空,表示修复成功。 --- $\boxed{4. \text{技术原理}}$ - **`LD_PRELOAD` 的作用**:强制程序运行时优先加载指定动态链接库 - **错误本质**:`libGLEW.so` 实际文件名通常包含版本号(如 `libGLEW.so.2.2.0`),直接指定 `libGLEW.so` 会导致链接失败 - **安全性**:注释该行不会影响系统功能,现代 MuJoCo/Gym 通常自动处理 OpenGL 依赖 --- $\boxed{5. \text{深度排查}}$ 若问题持续,检查以下内容: 1. **真实库路径**: ```bash ls /usr/lib/x86_64-linux-gnu/libGLEW* ``` 正常输出应包含类似 `libGLEW.so.2.2.0` 的实际文件。 2. **替代解决方案**: 若需保留 `LD_PRELOAD`(不推荐),可创建符号链接: ```bash sudo ln -s /usr/lib/x86_64-linux-gnu/libGLEW.so.2.2.0 /usr/lib/x86_64-linux-gnu/libGLEW.so ``` --- $\boxed{6. \text{预防措施}}$ - **避免手动设置 `LD_PRELOAD`**:除非明确知晓其用途 - **使用包管理器安装库**:优先通过 `apt` 安装而非手动下载 - **MuJoCo 用户注意**: ```bash pip install mujoco-py # 新版已集成必要依赖 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值