This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the unix category.
Last Updated: 2024-11-21
What would you do if strace
does not give you the info you need for debugging, if it seems
like it's hiding some of the action from you?
Advi Grim in his Ruby Tapas screencasts wanted to use strace
to see the calls
to getenv
(a command for getting environment variables) when running ruby bundle
.
But this failed to surface any useful info? Why?
Because getenv
is a library call, not a system call.
System calls and library calls are similar in that their functionality is provided to your application by the execution environment. The difference is that system calls are implemented in kernel, whereas library calls are implemented in user space.
Thus the distinction:
strace
just gives system calls.ltrace
(l stands for library) gives library callsltrace
Basically you need to tell it what library call to monitor and then the binary in question.
$ ltrace -e LIBCALL YOUR_BINARY ARGS
e.g. ltrace -e genenv bundle
Gotcha: If you try running with bundle
as above (the bundle command being
written in Ruby) it will fail since ltrace
wants a binary.
How to get around this? Well the ruby
command is a binary, so we modify
the call to ltrace
to use Ruby with the bundle
command as an argument:
$ ltrace -e getenv ruby /usr/local/bin/bundle
Tada!