this post was submitted on 10 Sep 2023
293 points (94.3% liked)

Programmer Humor

19503 readers
338 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 15 points 1 year ago (2 children)

When the issue is only seen after hours of runtime, logging is more practical.

[–] [email protected] 7 points 1 year ago (2 children)

I recently had an issue that happens on one out of between ten thousand and a hundred thousand interactions between two embedded processors. Thank god for logging!

[–] [email protected] 6 points 1 year ago

Even logging can sometimes be enough to hide the heisgenbug.

Logging to a file descriptor can sometimes be avoided by logging to memory (which for crash-safety includes the possibility of an mmap'ed file, since the kernel will just take care of them as long as the whole system doesn't go down). But logging from every thread to a single section of memory can also be problematic (even without mutexes, atomics can be expensive and certainly have side-effects) - sometimes you need a separate per-thread log, and combine in the log-reader tool.

[–] [email protected] 3 points 1 year ago

Well, conditional breakpoints exist.

But use whatever is easiest. People trying to micromanage how others use computers are the worst. And on the most popular languages by job count, your debuggers isn't all that more powerful than a well-constructed log anyway. (Hell, the people insisting that others adopt better tools should start with the language.)

[–] Omgpwnies 3 points 1 year ago

Or when the overhead of the debugger causes the issue to never happen