I used to work for a (no defunct) company, ARDI, that made a Mac emulator. We dynamically translated 68K to x86 and did a clean room reimplementation of Mac OS 9. (Yes, crazy.) Much of the job involved debugging the OS when running 3rd party software (binaries). The first step was to collect a syscall trace. Then lots of thought experiments. It was a great way to develop extreme debugging skills.
Syscall tracing works well for debugging applications or pieces of one that interact externally, or for ensuring that the OS is doing what you think it should, but I've found that more often than not the buggy part is "inside"; e.g. if an output file is incorrect, you would be able to see the incorrect data being written to it via the OS (which would've been clear from inspecting the file itself), but not what lead to that.<p>Coincidentally, I prefer to use an Asm-level debugger (WinDbg, OllyDbg) whenever I need to use one - which for debugging something I wrote, is not very often. Maybe it has to do with the fact that I started with Asm and disassembling other programs, so it's relatively straightforward to map between source code and the instructions the compiler generated. This also helped with figuring out a very subtle compiler bug - I know that they're quite rare, but when they do occur, they tend to be <i>extremely</i> difficult to figure out otherwise.
Great article, very interesting! I never knew about this :)<p>For those on OSX, `dtruss` seems to work in more-or-less the same way.<p><pre><code> sudo dtruss -t open ssh whatever.com
</code></pre>
More info on stack overflow: <a href="http://stackoverflow.com/questions/1925978/equivalent-of-strace-feopen-command-on-mac-os-x" rel="nofollow">http://stackoverflow.com/questions/1925978/equivalent-of-str...</a>
For those on Windows, the excellent System Internals suite contains "Process Monitor", which does pretty much what you'd expect, allowing you to see all sorts of file (and registry) activity.
Everytime I read about strace I feel guilty about not having tried it out.<p>Another awesome story: <a href="http://lwn.net/1999/0121/a/mec.html" rel="nofollow">http://lwn.net/1999/0121/a/mec.html</a>
Even though I havent followed the above idea ( I will try to do in sometime ), I have followed this way, which have helped me a lot.<p>I used to make guess when I debug my day to day problem. Say for example, when I run selenium, and the browser doesn't open up:<p>1. Does the jar is valid?
2. Safari has selenium plugin?
3. Have custom installation rather than default installation location?<p>Then the smart you make the guess, the smart you can solve the problem.<p>Its about removing the un-wanted space ( by making smart guess ) and debugging the right space.