←back to thread

376 points turrini | 2 comments | | HN request time: 0.001s | 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 #
1. mark_undoio ◴[] No.42147405[source]
> 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.

Debuggers can be great for understanding multithreaded code - and you can potentially freeze threads and continue others in order to provoke a particular race condition.

However they're potentially quite weak at stepping through a concurrency bug - stopping after each line to understand the sequence of events has a good chance of making your bug go away.

I'd say you want Time Travel Debugging if you need to capture and step through a rare event: you get to record the bug happening (without interrupting it) and then step through the recording.

On Linux, Undo.io (disclaimer: where I work) and rr (open source) are good at this.

On Windows, you have Microsoft's own Time Travel Debug solution: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

(nb. there's also GDB's built-in process record technology but I'd recommend against that for any non-trivial software as the overheads are very high)

replies(1): >>42148321 #
2. 0xfeba ◴[] No.42148321[source]
I've had logging slow down a concurrency issue enough to cause the race condition to never appear when logged, but setting a breakpoint (and stopping all threads) prevailed.