ltrace没输出主因是默认过滤或进程逃逸：仅跟踪动态链接库函数，不跟踪静态链接、libc内联优化调用及fork子进程（除非加-f）。
ltrace 为什么没输出？常见静默原因
多数时候 ltrace 看似运行了却没打印任何库调用，不是它坏了，而是被默认过滤或进程逃逸了。它只跟踪动态链接的库函数，默认不跟踪静态链接部分、libc 内联优化后的调用（比如小字符串操作常被编译器内联为指令），也不跟踪 fork 后子进程（除非加 -f）。
实操建议：
- 先确认目标程序确实动态链接：运行
ldd ./your_program，看到一堆libxxx.so才适合用ltrace - 加上
-s 256防止字符串被截断，加-t显示时间戳，加-f跟踪子进程（比如调用了system()或popen()） - 如果程序一启动就退出，试试
ltrace -e '*' ./your_program强制显示所有符号，排除过滤干扰
怎么只看某几个库函数？用 -e 和正则控制范围
ltrace 的 -e 参数不是简单白名单，它支持通配符和基础正则，但容易误以为“写了函数名就一定生效”。例如 -e "malloc" 会匹配 malloc、realloc、memalign —— 因为底层符号名可能带版本后缀（如 malloc@GLIBC_2.2.5），而 ltrace 默认做子串匹配。
实操建议：
- 查真实符号名：用
objdump -T /lib/x86_64-linux-gnu/libc.so.6 | grep malloc看导出符号，再写精准模式，比如-e "malloc@GLIBC_*" - 排除干扰：用
-e "!printf"屏蔽大量日志输出，或-e "read|write|open"只盯系统 I/O - 注意大小写：
ltrace默认区分大小写，-e "memcpy"不会捕获memcpy@GLIBC_2.14，得写成-e "memcpy*"
strace 和 ltrace 混用时谁在前谁在后？
想同时看系统调用和库调用，不能简单套壳执行 strace ltrace ./a.out——那样只会跟踪 ltrace 自身的系统调用，看不到目标程序行为。正确顺序是让 ltrace 作为主跟踪器，再让它把目标程序交给 strace，或者反过来用 strace -f -e trace=... 配合 ltrace -f 分开观察。
实操建议：
- 优先分两次跑：一次
ltrace -f -e "connect|send|recv" ./client，一次strace -f -e trace=connect,sendto,recvfrom ./client，对比更清晰 - 避免嵌套：不要
strace ltrace ...或ltrace strace ...，两者都依赖 ptrace，嵌套会导致权限冲突或跟踪失效 - 注意 PID 变化：若程序
fork多次，-f对两者都必要，否则只看到父进程
非 ELF 程序或 stripped 二进制还能用吗？
ltrace 依赖符号表（.dynsym）和动态重定位信息，对无符号的 stripped 程序，它仍能跟踪调用，但函数名会变成 0x7f8a1b2c3d4e 这类地址；对非 ELF 格式（比如某些 Go 编译的静态二进制），ltrace 直接报错 Not a dynamic executable，因为 Go 默认静态链接且不走 PLT。
实操建议：
- 检查格式：
file ./program必须输出ELF ... dynamically linked - 恢复可读性：用
readelf -Ws ./program | grep FUNC | head -20看有没有未剥离的符号；没有的话，地址跟踪只能靠反汇编交叉验证 - Go/Rust 程序慎用：它们常用自己的运行时调度，
ltrace捕获不到http.Get这类高层调用，得看perf trace -e 'syscalls:sys_enter_*'或语言专属工具
真正难的不是启动 ltrace，是分辨它“没输出”到底是程序没调库、调了但被优化掉、还是根本没走动态链接路径——这三者对应完全不同的排查方向。
