Programmer Humor

32490 readers

553 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.

founded 5 years ago

MODERATORS

[email protected]

852

My debugging experience today: Quantum Debugging (fedia.io)

submitted 2 months ago by [email protected] to c/[email protected]

66 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 53 points 2 months ago (2 children)

This is where printf debugging really shines, ironically.

[–] [email protected] 5 points 2 months ago* (last edited 2 months ago)

Honestly, this is why I tell developers that work with/for me to build in logging, day one. Not only will you always have clarity in every environment, but you won't run into cases where adding logging later makes races/deadlocks "go away mysteriously." A lot of the time, attaching a debugger to stuff in production isn't going to fly, so "printf debugging" like this is truly your best bet.

To do this right, look into logging modules/libraries that support filtering, lazy evaluation, contexts, and JSON output for perfect SEIM compatibility (enterprise stuff like Splunk or ELK).

[–] [email protected] 12 points 2 months ago (1 children)

I once had a racing condition that got tipped over by the debugger. So similar behavior to what's in the meme, but the code started working once I put in the print calls as well. I think I ended up just leaving the print calls, because I suck at async programming

[–] [email protected] 2 points 2 months ago

Yeah, I was going to mention race conditions as soon as I saw the parent comment. Though I'd guess most cases where the debugger "fixes" the issue while print statements don't are also race conditions, just the race isn't tight enough that that extra IO time changes the result.

Best way to be thorough with concurrency testing IMO involves using synchronization to deliberately check the results of each potential race going either way. Of course, this is an exponential problem if you really want to be thorough (like some races could be based on thread 1 getting one specific instruction in between two specific instructions in thread 2, or maybe a race involves more than 2 threads, which would make it exponentially grow the exponential problem).

But a trick for print statement debugging race conditions is to keep your message short. Even better if you can just send a dword to some fast logger asynchronously (though be careful to not introduce more race conditions with this!).

This is one of the reasons why concurrency is hard even for those who understand it well.