目录
一、前言——ltrace 工具简介
1.1 什么是 ltrace
1.2 与 strace / gdb 的对比
1.3 能跟踪什么、不能跟踪什么
二、使用场景——何时使用 ltrace
1、程序行为「像调了某个 API」但源码里找不到
2、排查内存分配异常
3、对比 strace：库函数层 vs 系统调用层
4、定位第三方闭源 .so 的行为
5、attach 已运行进程
6、统计库函数调用频次（性能粗分析）
三、核心原理——工作原理深度解析
3.1 总体思路：拦截 PLT 跳转
3.2 与 strace 的分工
3.3 实现方式（概念级）
3.4 性能影响
四、命令参数——常用选项详解
4.1 基本用法
4.2 输出格式解读
4.3 常用选项
五、使用实战——实际案例分析
案例 1：基础库函数跟踪
案例 2：过滤跟踪，减少噪音
案例 3：统计调用次数（-c）
案例 4：attach 运行中的服务
案例 5：跟踪指定动态库
案例 6：带时间戳与耗时
六、常见问题——疑难解答
七、总结——要点回顾
一、前言——ltrace 工具简介
1.1 什么是 ltrace
ltrace（library trace）是 Linux 下的 动态库函数调用跟踪工具，用于记录进程在运行时调用了哪些 共享库（.so）中的函数，以及 参数、返回值、耗时 等信息。
一句话定位：
ltrace 是用户态程序的 「库函数显微镜」 —— 不用改代码、不用 gdb 单步，就能看清 printf、malloc、fopen 等 libc 调用链。
1.2 与 strace / gdb 的对比
|
ltrace |
库函数（libc、libpthread 等） |
malloc(128) = 0x… |
看业务代码调了哪些 API |
|
strace |
系统调用（内核接口） |
openat(…) = 3 |
看文件/网络/进程 syscall |
|
gdb |
断点 + 单步 + 变量 |
交互式调试 |
已知崩溃点深入分析 |
|
perf |
CPU 采样 / 计数 |
热点函数栈 |
性能瓶颈 |
关系示意：
你的代码: printf(\”hi\”) → fwrite(…) → write(1, …)
↑ ltrace 看到 ↑ ltrace 可能看到 ↑ strace 看到
ltrace 优势： 直接对应 C 标准库 / POSIX API，比 strace 更接近程序员日常写的函数名。
1.3 能跟踪什么、不能跟踪什么
|
动态链接的 libc（glibc/musl） |
静态链接 的 libc（-static） |
|
libpthread、libm、libdl 等 .so |
内联函数、编译器优化掉的调用 |
|
通过 PLT 调用的外部符号 |
无符号 / 被 strip 的私有 .so（名可能不全） |
|
子进程（-f） |
内核模块、内核态代码 |
二、使用场景——何时使用 ltrace
1、程序行为「像调了某个 API」但源码里找不到
典型现象：
-
日志里出现文件读写，但业务代码没有直接 open
-
怀疑第三方库在偷偷 fopen / getenv
ltrace -e fopen+fopen64+open+openat ./app
2、排查内存分配异常
典型现象：
-
内存持续增长，不确定谁在 malloc
-
怀疑某路径重复 calloc 未 free
ltrace -e malloc+free+realloc+calloc -f ./app 2>&1 | tee mem.log
3、对比 strace：库函数层 vs 系统调用层
典型现象：
-
strace 看到大量 write，不知道是 printf 还是 fwrite
-
需要把 业务 API 和 底层 syscall 对上号
# 库函数层
ltrace -f ./app
# 系统调用层
strace -f ./app
# 同时看（部分版本支持）
ltrace -S -f ./app
4、定位第三方闭源 .so 的行为
ltrace -l libvendor.so ./app
# 或
ltrace -e \’@libvendor.so\’ ./app
5、attach 已运行进程
ltrace -p $(pidof my_service)
6、统计库函数调用频次（性能粗分析）
ltrace -c ./app
