[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.