ltrace: Usage, Options & Common CI Errors

ltrace shows the dynamic library calls a program makes, with arguments.

ltrace is strace for library calls: it reveals which libc/library functions (malloc, fopen, SSL_connect) a program invokes. It is less robust than strace - static and some PIE binaries defeat it - and shares the ptrace permission requirement.

What it does

ltrace intercepts dynamic library function calls (and, with -S, system calls) made by a program, printing each call’s arguments and return value. It works by hooking the PLT of dynamically linked binaries.

Common usage

Terminal

ltrace ./app                       # trace library calls
ltrace -f ./app                    # follow children
ltrace -e 'malloc+free' ./app      # only these functions
ltrace -S ./app                    # also show syscalls
ltrace -c ./app                    # summary counts

Options

Flag	What it does
-f	Follow child processes
-e <filter>	Restrict to named functions
-S	Also trace system calls (like strace)
-c	Summarize call counts and time
-p <pid>	Attach to a running process

Common errors in CI

"Couldn’t find .dynsym or .dynstr in ‘./app’" or empty output means the binary is statically linked (no PLT to hook) - ltrace only sees dynamic calls; use strace instead. The "ptrace: Operation not permitted" container restriction applies as with strace/gdb (needs SYS_PTRACE). On some distros/arches ltrace is unmaintained or hooks PIE binaries poorly, producing partial traces - cross-check with strace -e when results look incomplete.