ltrace: Trace Library Calls
ltrace runs a program and records the calls it makes into dynamic libraries, such as malloc or strlen, similar to how strace records syscalls.
Where strace shows the kernel boundary, ltrace shows the library boundary. It is useful for seeing how a program uses libc or another shared library without source.
What it does
ltrace intercepts calls from a program into shared libraries and prints each with its arguments and return value. With -c it prints a summary of call counts and time per library function; -f follows child processes.
Common usage
ltrace ./my-program
# summary of library calls with counts and time
ltrace -c ./my-program
# follow children and log to a file
ltrace -f -o ltrace.log ./my-programOptions
| Flag | What it does |
|---|---|
| -c | Summary table of calls, time, and counts |
| -f | Follow child processes |
| -e <filter> | Only trace matching functions |
| -S | Also trace system calls (like strace) |
| -p <pid> | Attach to an existing process |
| -o <file> | Write output to a file |
In CI
ltrace is best for ad hoc debugging of library usage, not automated gates. Like strace it relies on ptrace, so containers need --cap-add SYS_PTRACE. On modern position-independent executables its coverage can be limited, so treat results as a guide.
Common errors in CI
"Couldn't find .dynsym or .dynstr" or empty output on a statically linked or heavily optimized PIE binary means ltrace cannot resolve the library calls; it works best on dynamically linked executables. "ptrace: Operation not permitted" in Docker is the same ptrace restriction strace hits; add SYS_PTRACE. ltrace is also missing from many minimal images and must be installed.