Have you ever been the victim of a bug in a programming language or technology?

Question

Bugs can be difficult enough to resolve when they're your (or a coworker's) fault. However, we all know that the technology we use to implement our programs is written by infallible people such as ourselves. So it stands to reason that some people have been affected by bugs in the implementation of the tools they used.

So, have you found a bug in your program that was caused by a widespread underlying technology, such as a programming language or framework? If so, did it fail with some indication, or did it silently overwrite some data? How difficult was it to debug? Did it cause a potential security vulnerability? Were you able to contact the provider and confirm that it was fixed (or fix it yourself)?

Here are some of the worst (in my opinion) technologies to have a bug in (especially one that fails silently):

• Programming language
• Concurrency framework
• Remote API
• Database

Answer 1

I guess almost anyone who has programmed JavaScript with Internet Explorer has found a bug in their program which was caused by a widespread underlying technology.

The indication of failure is the blue "e" on your Windows desktop.

Answer 2

I deal with one on a daily basis called Internet Explorer.

To be fair though, there are lots of bugs in all of the browsers. I have filed several bugs for Firefox as well, and just the other day I found a strange case where the border doesn't take padding into consideration.

Answer 3

This is a good argument for writing lots of unit tests. If you upgrade your platform to a newer version that has some new bug, hopefully you have a test that reveals the bug

in one case I had, the vendor was working on a brand new API. They were not ready to release the new API, but they were not very keen to fix the bug in the old one either as they considered it dead from a $$ perspective.

Answer 4

A colleague once stumbled across a bug in the Jikes Java compiler. He had something like this:

if (condition)
{
}
else
{
   System.out.println("Code that does stuff.");
}

He hadn't intended to leave the top block empty permanently, but just had it that way during development. He discovered that the condition was ignored unless he put a comment in that block so that it was no longer empty.

Answer 5

I've run into something with the gcc 4.4.0 but as the product I'm currently working on is still pre-alpha, it was fairly easy to repair locally. Hopefully they'll fix it soon.

Answer 6

The first that comes to mind was with version 1 of the .NET Framework; for some reason, Random.NextDouble() method never produced a value greater than 0.5. I was completely baffled, and having run a test apps that called the method thousands and thousands of times, I had to presume it was a bug and work round it.

Never did find out what the cause was...

Answer 7

During my time developing (mostly) with Java I've run into bugs in the following components:

• Java compiler
  • This actually happened several times. Usually we found that ecj (the Eclipse compiler) and javac (the Sun compiler) disagree about the validity of some Java code. Usually I enter bug reports for both systems, one of them gets accepted and the other one is closed as invalid.
• Database engine
  • Those are very rare and very, very nasty, because no one expects the DB itself to have a bug. In our case it was an old product (the bug was already fixed in a newer release) that accepted values in a field that were not within the defined range (similar to having a NOT NULL field containing NULL)
• JDBC driver
  • There were several bug fixes to a JDBC driver due to a project I've been working on. The bug fixes ranged from trivial ("why is there debug output in the production release?") to might-not-even-be-a-real-bug ("you can easily safe one roundtrip per statement by doing that-and-that").
• JVM implementations
  • those are hard to diagnose and often present themselves as effectively random crashes on one JVM and stable operation on another one. We temporarily switched JVM vendor several times due to things like this.

Each time it took quite some time (and usually the involvement of the vendor of the component) before I actually believed it was a bug in that component.

And yes: the cases of false positives (i.e. the bug was actually in my/our code) were orders of magnitude more common.

The only place where bugs in the third-party component are kind-of expected seem to be web browsers. Almost no one questions you when you say "that's a bug in <insert buggy browser of the week>, we need to work around it like this ...".

Answer 8

i found a very strange bug in gcc on Mipsel (openwrt). We was testing a small app (about 3K sloc) that give me sigsev even if the code was corrected in theory.

I don't know the detail of the bug (and I don't have that code anymore) but change the gcc version from 4.1 to 3.6 solve the problem.