[vram22]

And what if your bug is after the nth iteration of the loop, where the exact value of n is unknown (it's a bug, after all)? How many times are you going to set the variable and run the loop n times? Whereas with print-debugging and a grep you can filter for only unexpected/unusual output, and so narrow down to the likely cause, faster. Generalizing, of course. There are definitely cases where a debugger can be more effective, as others in this thread have said. It depends on the case.

[ori_b]

I'd set a conditional breakpoint:

    (gdb)> break <some-location>
    Breakpoint 1 at ....
    (gdb)> cond 1 x < 42
    (gdb)> cont

And now, it will execute until 'x < 42' is true. If the bug is that you always expect 'x > 42', then it triggers.

Although, to be honest, I mostly use a debugger as an exploratory printf these days:

     (gdb)> call pretty_print(my_data)

I do mainly use printf as the front line of debugging, though, with several debug switches on the command line. I follow up by jumping to a debugger once I have an idea of where things are going wrong, and I can poke around at the state.

I also need to look into backwards stepping. GDB can trace executions of the program, and when you see the issue pop up, you can step backwards in time to see what caused it.

[vram22]

Backward stepping is cool. When I was checking out various Lisps some time ago, I saw in (IIRC) Franz Lisp that they had something like Visual Studio's Edit and Continue (maybe before VS did). Not a Lisper myself, though I've dabbled in it now and then and like it, so maybe that has been a feature of Lisps from much before - don't know.

[vram22]

Link saying what VS Edit and Continue is:

http://msdn.microsoft.com/en-us/library/vstudio/bcew296c.asp...

[vram22]

Yes, conditional breakpoints can be helpful - good point. You missed the case of x == 42, in a hurry, I guess. cond should be x <= 42.