←back to thread

376 points turrini | 4 comments | | HN request time: 0.914s | source
Show context
rkharsan64 ◴[] No.42146864[source]
On a general note, I would recommend any new (and experienced!) programmers to master the debugging tools of their ecosystem. I've seen countless experienced developers use printf-based debugging and waste hourse debugging something which could've been easily figured out by setting a breakpoint and stepping through your code. This is also a good way to understand code you're unfamiliar with.

This is one area where I believe a GUI tool is so much better: I can hover over variable names to view their values, expand and collapse parts of a nested structure, edit values easily, and follow execution in the same environment I write my code in.

Sure, it doesn't help much for some scenarios (one I've heard people mention is multithreaded code, where logs are better?), but for most people it's not that far from a superpower.

replies(13): >>42147055 #>>42147066 #>>42147101 #>>42147176 #>>42147333 #>>42147405 #>>42147537 #>>42147789 #>>42147794 #>>42148121 #>>42148413 #>>42149115 #>>42152454 #
VyseofArcadia ◴[] No.42147055[source]
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.

replies(3): >>42147372 #>>42147615 #>>42149899 #
cevn ◴[] No.42147615[source]
In Jetbrains you can also do a Conditional breakpoint to active only if i=100 or something.
replies(1): >>42147811 #
1. VyseofArcadia ◴[] No.42147811[source]
Well yeah, but I didn't know I wanted i = 100 until I had examined the fprintf output.
replies(1): >>42147889 #
2. gregthelaw ◴[] No.42147889[source]
You need a time travelling debugger!

https://undo.io/

https://rr-project.org/

https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

replies(1): >>42148501 #
3. amlib ◴[] No.42148501[source]
What happens if the loop executes some non-idempotent calls? I guess printf debug still has some value :)
replies(1): >>42149383 #
4. mark_undoio ◴[] No.42149383{3}[source]
> 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.