Hacker News new | ask | show | jobs
by TremendousJudge 619 days ago
Sometimes an interactive debugger session will make the issue you are researching not happen -- I don't know of a way of tracking down race conditions that isn't logging everything that happens until I find out which thing happened before which other thing that wasn't supposed to
2 comments
Terr_ 619 days ago
> Sometimes an interactive debugger session will make the issue you are researching not happen

I still remember the first time that happened to me, I think it had to do with some (not yet diagnosed) race condition on a PHP server between the HTTP requests it served, and the debugger had a side-effect of blocking the next request while I was inspecting the first one.

That reminds me of another thing: Some debuggers allow you to set breakpoints and set them to not suspend or pause execution, but to emits a log-message to the debugger or terminal instead.

Those are an upgrade over print-statements in that:

1. You can't accidentally commit it and it doesn't show up to make your diffs weird

2. You may be able to dynamically change what things it prints out without restarting the program

link
eastbound 619 days ago
And the reverse: I change values using breakpoints. So the code runs (because the breakpoint condition is false) but the value is different. Example of breakpoint condition:

(licenseActive = true) != true

link