In many years of programming, I don't think I've ever run into a genuine compiler bug. It's fallacy to assume they don't exist, but they tend to be so rare and esoteric that you probably have a better chance of winning the lottery than finding one.
I have however, run into numerous bugs in standard libraries. These are definitely much more common in proprietary languages like ActionScript (Flash) or Lingo (Director), or rapidly-changing (I'll be nice and not say poorly designed) languages like PHP than in say, C, C++ or Java. Platform-specific bugs in x-platform code also seem to be the most common.
I agree with the general premise that "it's probably your own fault". I can probably count more times that I've suspected a compiler/OS/stdlib bug and found after extensive testing that it was my own fault than I can count genuine library bugs. On average, I probably hit one genuine language bug every two years at most.
The trick is to start with the assumption that it is a compiler/OS/stdlib bug. Next, go create a minimal proof-of-concept to demonstrate the bug you believe exists. In doing so, more than 50% of the time you'll figure out what was really wrong with your code as you are doing this. The other times, you have a nice minimal test case you can submit to the language maintainer's mailing list.
It's also surprising how much you can learn about how a language or feature by trying to methodically prove that it is broken. The process of doing so forces you to think about all the edge cases you don't normally consider, but most of the time, the language designer already did.
I have however, run into numerous bugs in standard libraries. These are definitely much more common in proprietary languages like ActionScript (Flash) or Lingo (Director), or rapidly-changing (I'll be nice and not say poorly designed) languages like PHP than in say, C, C++ or Java. Platform-specific bugs in x-platform code also seem to be the most common.
I agree with the general premise that "it's probably your own fault". I can probably count more times that I've suspected a compiler/OS/stdlib bug and found after extensive testing that it was my own fault than I can count genuine library bugs. On average, I probably hit one genuine language bug every two years at most.
The trick is to start with the assumption that it is a compiler/OS/stdlib bug. Next, go create a minimal proof-of-concept to demonstrate the bug you believe exists. In doing so, more than 50% of the time you'll figure out what was really wrong with your code as you are doing this. The other times, you have a nice minimal test case you can submit to the language maintainer's mailing list.
It's also surprising how much you can learn about how a language or feature by trying to methodically prove that it is broken. The process of doing so forces you to think about all the edge cases you don't normally consider, but most of the time, the language designer already did.