A recent “why is this process hanging?” I needed to turn to strace for: a daemon was trying to send mail out, but it had either connected to a STARTTLS-capable port expecting TLS, or vice versa, forget which. It hung until timeout because the handshake wasn’t working in any way, and of course it couldn’t email me the error report like it was meant to. At this stage I didn’t even know it was a mail issue. Seeing the process writing one thing to the socket and receiving another (i.e. plain SMTP one way and TLS handshake the other) made it clear as day where I’d misconfigured it.
strace is an invaluable tool for reverse engineering and learning. Recently I wanted to know exactly what happened when I played with a Rust io_uring wrapper. I could see how syscalls were made to learn more about it. I did the same when I wanted to quickly know how tail -f was implemented under the hood without reading any C source code. (Btw, it uses inotify + epoll if I remember correctly.)
I saw the headline and started thinking about it some before reading the article… only to discover that I’ve used strace on all the problems they’ve listed. Fantastic list!
Procmon is the closest equivalent, but Portmon and ProcDump, alongside the tightly-related-but-different Spy++, can also be very useful in this context (some of those being closer to e.g. ltrace than strace, specifically, but the division of responsibilities on Windows are a bit different, so there’s not a one-to-one mapping).
Strace saved me last week because borked up make compile stuff had led a c binary to expect /etc to be in some weird location and with strace I could see that👍
strace is one of my debugging tools of first resort, along with tcpdump.
I’ve used it in all but one of the situations described in the article.
I didn’t realize it could be used for some quick and dirty profiling. TIL.
A lot of times, I reach for strace because some program terminates with
a context-free error message, like “no such file or directory”,
“operation not supported”, etc.
For problem 7, determining the command-line arguments being passed to a
called program, there’s a great tool for this called extrace.
You can find it at leahneukirchen/extrace on github.
Just start it up, and watch the exec syscalls that are being made by
anything on the system.
I found strace incredibly helpful to understand how shells work under the hood, it can highlight why something like ls | read var; echo "$var" produces different results between bash and zsh for instance (last pipeline member forked in bash).
A recent “why is this process hanging?” I needed to turn to strace for: a daemon was trying to send mail out, but it had either connected to a STARTTLS-capable port expecting TLS, or vice versa, forget which. It hung until timeout because the handshake wasn’t working in any way, and of course it couldn’t email me the error report like it was meant to. At this stage I didn’t even know it was a mail issue. Seeing the process writing one thing to the socket and receiving another (i.e. plain SMTP one way and TLS handshake the other) made it clear as day where I’d misconfigured it.
ltrace is also quite useful.
I’ve always felt like my usage of strace was very contrived, but this makes me feel much better, thank you!
straceis an invaluable tool for reverse engineering and learning. Recently I wanted to know exactly what happened when I played with a Rustio_uringwrapper. I could see how syscalls were made to learn more about it. I did the same when I wanted to quickly know howtail -fwas implemented under the hood without reading any C source code. (Btw, it usesinotify+epollif I remember correctly.)I saw the headline and started thinking about it some before reading the article… only to discover that I’ve used strace on all the problems they’ve listed. Fantastic list!
Is there a working strace equivalent for Windows? It’s the tool I always miss when I have to debug anything there.
Procmon?
Procmon is the closest equivalent, but Portmon and ProcDump, alongside the tightly-related-but-different Spy++, can also be very useful in this context (some of those being closer to e.g.
ltracethanstrace, specifically, but the division of responsibilities on Windows are a bit different, so there’s not a one-to-one mapping).procmon seems to work well, thanks for the suggestion!
Strace saved me last week because borked up make compile stuff had led a c binary to expect /etc to be in some weird location and with strace I could see that👍
strace is one of my debugging tools of first resort, along with tcpdump. I’ve used it in all but one of the situations described in the article. I didn’t realize it could be used for some quick and dirty profiling. TIL.
A lot of times, I reach for strace because some program terminates with a context-free error message, like “no such file or directory”, “operation not supported”, etc.
For problem 7, determining the command-line arguments being passed to a called program, there’s a great tool for this called extrace. You can find it at leahneukirchen/extrace on github. Just start it up, and watch the exec syscalls that are being made by anything on the system.
I found strace incredibly helpful to understand how shells work under the hood, it can highlight why something like
ls | read var; echo "$var"produces different results between bash and zsh for instance (last pipeline member forked in bash).