Reputation: 23321
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):
Upvotes: 4
Views: 320
Reputation: 385
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.
Upvotes: 0
Reputation: 308131
During my time developing (mostly) with Java I've run into bugs in the following components:
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 ...".
Upvotes: 2
Reputation: 7332
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.
Upvotes: 0
Reputation: 2077
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...
Upvotes: 0
Reputation: 54495
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.
Upvotes: 2
Reputation: 304355
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.
Upvotes: 2
Reputation: 58949
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.
Upvotes: 7
Reputation:
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.
Upvotes: 1