In this case, it’s not clear that the compiler was really wrong. The results of a floating point calculation differed by a tiny amount, and it’s possible that either was acceptable (I don’t know how strict Java is about its floating point rules). The problem was that I was using the result as a hash key.
But later, I was able to make the JVM reliably dump core (in different memory locations each time). Unfortunately, it was only under extremely heavy load, and I was never able to build a reduced test case.
Compilers do get things wrong. You may be interested in John Regehr’s blog; he’s essentially throwing cleverly-chosen “random” input at C compilers (“fuzz-testing”). The results are similar to those for other programs that have never been fuzzed, i.e. embarrassing.
Well, your prior should be pretty high that it’s your fault, unless you also wrote the compiler :)
If you can do experiments to prove that there’s a compiler bug, you learn something. If you jump straight to the compiler bug explanation instead of looking for the bug in your own code, you are resisting education, and the probability that all you are doing is delaying the lesson is the probability that the compiler is working correctly. This should be >>50% of the time or you need a better compiler!
The difference here is not so much in where you guess the bug is, as in whether you do the experiment.
A very effective experiment is to take your program and chop out everything irrelevant until you have a short piece of code which demonstrates the bug. At this point, if it is a compiler bug, you have dense information to hand the compiler author; if it isn’t a compiler bug, you’re in a much better position to understand what’s wrong with your code.
However, one is often reluctant to apply this technique until one suspects a compiler bug, because it seems like a lot of work. And it is — but often less work than continuing to examine the bug with less radical tools, given that you’re in the position where the notion of compiler bugs crosses your mind.
Wow. An actual exception to “The compiler is never wrong!”
In this case, it’s not clear that the compiler was really wrong. The results of a floating point calculation differed by a tiny amount, and it’s possible that either was acceptable (I don’t know how strict Java is about its floating point rules). The problem was that I was using the result as a hash key.
But later, I was able to make the JVM reliably dump core (in different memory locations each time). Unfortunately, it was only under extremely heavy load, and I was never able to build a reduced test case.
Compilers do get things wrong. You may be interested in John Regehr’s blog; he’s essentially throwing cleverly-chosen “random” input at C compilers (“fuzz-testing”). The results are similar to those for other programs that have never been fuzzed, i.e. embarrassing.
And yet, in practice, when something is wrong with your code, it’s always your own fault.
Well, your prior should be pretty high that it’s your fault, unless you also wrote the compiler :)
If you can do experiments to prove that there’s a compiler bug, you learn something. If you jump straight to the compiler bug explanation instead of looking for the bug in your own code, you are resisting education, and the probability that all you are doing is delaying the lesson is the probability that the compiler is working correctly. This should be >>50% of the time or you need a better compiler!
The difference here is not so much in where you guess the bug is, as in whether you do the experiment.
A very effective experiment is to take your program and chop out everything irrelevant until you have a short piece of code which demonstrates the bug. At this point, if it is a compiler bug, you have dense information to hand the compiler author; if it isn’t a compiler bug, you’re in a much better position to understand what’s wrong with your code.
However, one is often reluctant to apply this technique until one suspects a compiler bug, because it seems like a lot of work. And it is — but often less work than continuing to examine the bug with less radical tools, given that you’re in the position where the notion of compiler bugs crosses your mind.