3 ms·
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
by ori_b 13y ago
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 13y agoYes, conditional breakpoints can be helpful - good point. You missed the case of x == 42, in a hurry, I guess. cond should be x <= 42.
- vram22 13y agoBackward 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 13y agoLink saying what VS Edit and Continue is: http://msdn.microsoft.com/en-us/library/vstudio/bcew296c.aspx http://msdn.microsoft.com/en-us/library/vstudio/bcew296c.asp...