3 ms·

But also, experienced programmers should never forget their printf debugging roots. I was debugging something earlier this week that was hit like a hundred tim

But also, experienced programmers should never forget their printf debugging roots. I was debugging something earlier this week that was hit like a hundred times in a tight loop. After the first dozen or so times I told gdb to continue, I realized, wait, this will be faster if I just fprintf some relevant information to a file. Sure enough the file pointed me in the right direction, and I was able to go back and get fancy with "disp" and "cond" and hit that breakpoint only when I needed to.

mark_undoio 2y ago
You could also use GDB's Dynamic Printf (https://sourceware.org/gdb/current/onlinedocs/gdb.html/Dynamic-Printf.html https://sourceware.org/gdb/current/onlinedocs/gdb.html/Dynam...) to do the logging directly from GDB. Essentially you set it like a breakpoint (attaching a printf style string to a code location) and then just "continue" until you've gathered what you want.
- VyseofArcadia 2y ago
  Oh sweet. I didn't know about that. I will be adding that to my toolbox.
cevn 2y ago
In Jetbrains you can also do a Conditional breakpoint to active only if i=100 or something.
- VyseofArcadia 2y ago
  Well yeah, but I didn't know I wanted i = 100 until I had examined the fprintf output.
  - gregthelaw 2y ago
    You need a time travelling debugger! https://undo.io/ https://undo.io/ https://rr-project.org/ https://rr-project.org/ https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/time-travel-debugging-overview https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
    - amlib 2y ago
      What happens if the loop executes some non-idempotent calls? I guess printf debug still has some value :)
      - mark_undoio 2y ago
        > What happens if the loop executes some non-idempotent calls? I guess printf debug still has some value :) Then they'll do the same thing when you replay. Non-idempotent system calls are tricky because they interact with the outside world - but that's still OK. In Time Travel Debug, the process you're debugging is essentially in the Matrix. When it's being recorded everything acts as normal (and it'll see the real results of those non-idempotent calls). When it's being debugged, any interaction with the outside system is prevented and replaced with the behaviour we saw at record time. It'll still think it's doing the non-idempotent calls, they just won't change (or depend upon) the state of the rest of the system.
slashdave 2y ago
Um, is it okay to admit, as an "experienced" programmer, that I often resort to print statements? I mean, compilers are just so darn fast these days. Another trick: for rare circumstances, code whatever complicated logic is needed to isolate the bug in order to issue a print statement, then use the debugger to break on that print statement.

mark_undoio 2y ago

You could also use GDB's Dynamic Printf (https://sourceware.org/gdb/current/onlinedocs/gdb.html/Dynamic-Printf.html https://sourceware.org/gdb/current/onlinedocs/gdb.html/Dynam...) to do the logging directly from GDB. Essentially you set it like a breakpoint (attaching a printf style string to a code location) and then just "continue" until you've gathered what you want.

VyseofArcadia 2y ago
Oh sweet. I didn't know about that. I will be adding that to my toolbox.

cevn 2y ago

In Jetbrains you can also do a Conditional breakpoint to active only if i=100 or something.

VyseofArcadia 2y ago
Well yeah, but I didn't know I wanted i = 100 until I had examined the fprintf output.
- gregthelaw 2y ago
  You need a time travelling debugger! https://undo.io/ https://undo.io/ https://rr-project.org/ https://rr-project.org/ https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/time-travel-debugging-overview https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
  - amlib 2y ago
    What happens if the loop executes some non-idempotent calls? I guess printf debug still has some value :)
    - mark_undoio 2y ago
      > What happens if the loop executes some non-idempotent calls? I guess printf debug still has some value :) Then they'll do the same thing when you replay. Non-idempotent system calls are tricky because they interact with the outside world - but that's still OK. In Time Travel Debug, the process you're debugging is essentially in the Matrix. When it's being recorded everything acts as normal (and it'll see the real results of those non-idempotent calls). When it's being debugged, any interaction with the outside system is prevented and replaced with the behaviour we saw at record time. It'll still think it's doing the non-idempotent calls, they just won't change (or depend upon) the state of the rest of the system.

slashdave 2y ago

Um, is it okay to admit, as an "experienced" programmer, that I often resort to print statements? I mean, compilers are just so darn fast these days. Another trick: for rare circumstances, code whatever complicated logic is needed to isolate the bug in order to issue a print statement, then use the debugger to break on that print statement.