War story: the hardest bug I ever debugged

(www.clientserver.dev)

462 points jakevoytko | 1 comments | 24 Mar 25 14:37 UTC | HN request time: 0.201s | source

Show context

latexr ◴[27 Mar 25 09:53 UTC] No.43491859[source]▶

> I do it a few more times. It’s not always the 20th iteration, but it usually happens sometime between the 10th and 40th iteration. Sometimes it never happend. Okay, the bug is nondeterministic.

That’s an incorrect assumption. Just because your test case isn’t triggering the bug reliably, it does not mean the bug is nondeterministic.

That is like saying the “OpenOffice can’t print on Tuesdays” is non deterministic because you can’t reproduce it everyday. It is deterministic, you just need to find the right set of circumstances.

https://beza1e1.tuxen.de/lore/print_on_tuesday.html

From the writing it appears the author found one way to reproduce the bug sometimes and then relied on it for every test. Another approach would have been to tweak their test case until they found a situation which reproduced the bug more or less often, trying to find the threshold that causes it and continuing to deduce from there.

replies(2): >>43493111 #>>43494573 #

artimaeis ◴[27 Mar 25 12:56 UTC] No.43493111[source]▶

>>43491859 #

If I understood correctly - the Math.Abs() value would be positive roughly half the time, regardless of the steps taken to get there. That seems definitively nondeterministic.

replies(2): >>43493557 #>>43493654 #

1. nogridbag ◴[27 Mar 25 13:41 UTC] No.43493557[source]▶

>>43493111 #

My interpretation was it was replaced with the identity function (e.g. just returning the original value). But it's only replaced if the code is determined to be a hot spot. So it would work correctly until the code was in a tight loop, then it would start failing once passed a negative number.

↑