Most of the time, by looking at a backtrace (I primarly debug C stuff, by the way), I already have a good idea what the problem might be. Tracking that down in

Most of the time, by looking at a backtrace (I primarly debug C stuff, by the way), I already have a good idea what the problem might be. Tracking that down in a debugger is horribly inefficient, especially if optimisations are involved (how may times did you try to print a local variable, or a parameter, only to be greeted with <this value has been optimized out>?), so another way to see the program flow is required. printf() does wonders in this area, if you can put them at the right places. Over the years, I found and fixed far more issues with printf() than with a debugger. Granted, sometimes a debugger is neccessary, at least until I understand the problem, and become able to reproduce it. Then printfs it is again. If I can't reproduce it, and only have a core file to work with, then, obviously, a debugger is one's only choice. If I need to extract information from a core dump, a debugger is the way to go again. But when trying to examine running code, printfs are - in my experience - more straightforward to work with.