Pet Bugs?

benreece asks: "During my few years as a programmer/developer I've come across some strange bugs. Recently I found that Microsoft's VB/VBScript(ASP) round function has problems (for example, 'round(82.845)' returns '82.84' instead of '82.85'). It took me an annoyingly long time to realize the problem wasn't mine. I'm wondering what other obscure, weird, and especially annoying bugs in languages/compilers/etc have frustrated other developers." Memorable bugs. Every developer has one. What were yours?

Comments

Spider

[peterdaly]

We have a spider that comes crawling around our cubes every now and then. We don't kill him, figuring he helps keep the other bug populations inside down. We call him our little web developer.

I'm serious.

-Pete

My favorite browser "feature"

[SuperMallen]

I worked a wicked long time ago on the HotJava browser, and we were forever running into strange behaviors in the ways IE and Netscape handled what looked like normal HTML tags.

My favorite was a bug we saw with a three column table. The table's three cells were specified like this:

<td width="31"></td><td width="42></td><td width="29"></td>

Being a good little HTML-compliant browser, HotJava displayed them with those pixel widths. But lo and behold! When displayed in Netscape, the table filled the screen.

We bashed our heads against the wall to figure this out until we realized that the numbers added up to almost, but not quite, 100. Netscape was treating them as percentages rather than pixel widths, even though they lacked percent signs. The cutoff turned out to be somewhere around 104 to 96. Anywhere in there and the browser would assume percentages.

strtok

[sdjunky]

this has to be the most memorable one.

it's in the Linux man file

BUGS
Never use this function. This function modifies its first argument. The identity of the delimiting character is lost. This function cannot be used on constant strings.

Current bug in Windows I/O....

[Kris Warkentin]

I just observed this bug a while ago while porting some software to windows. Do the following:

fopen some file for writing.
write some stuff.
fseek to some offset near the beginning.
write some more stuff.
fclose.

Simple right? Wrong. I observed that the second write didn't get performed unless you explicitly do a fflush before the close. Imagine, not writing dirty buffers out on a fclose....unbelievable.

You think YOU had a rounding bug????

[flatulus]

Get this: A few years ago I was doing real-time driver development for an embedded DSP subsystem using TI 54X processors. Months into the development, one of the processors started "losing" a serial port transmitter interrupt. This was an interrupt that (kinda like a machine gun) *MUST* fire every time, or it will never fire again.

This was a major issue, because when the interrupt was lost the system froze up and had to be rebooted (this is an embedded app - not a desktop).

I offered to assist the engineer responsible for this code. We spent two days tracing the problem in extreme detail, checking and cross-checking our results. We both concluded that the processor was simply "losing" the interrupt. There was no rational explanation. We adopted the countermeasure of using a fine grain watchdog timer to look for the lost interrupt. This isn't the best solution, since what was to keep the watchdog interrupt from being lost??? But it was the best we could do. And it worked.

The project lead, however, was very unhappy with our solution. He was convinced that we had overlooked the cause of the problem, which had to be software-based. I countered that, though he could certainly be right, it would be better to leave the watchdog in and let the project move ahead until we stumbled across the real cause in due time. He reluctantly accepted this approach.

My vindication took five months, but what sweet irony when it did. It turned out that some other company, which also used the 54X chip, had encountered the same problem, but they figured it out (and I'll never know how). The problem was that the 54X (at that time) had a silicon flaw that, when certain integer rounding instructions executed at the same instant that an interrupt were being asserted, the interrupt could be "lost". This was confirmed by TI to be a silicon fault, and no amount of software handstands or cartwheels could fix it. The only workaround was to not use those rounding instructions!

OK- top that....

6502 microcode bugs...

[schon]

My all-time favourite bug is in the microcode of the 6502/6510...

An indirect jump where the source address was on a page boundary caused the high-byte to be pulled from the beginning of the current page, instead of the beginning of the next page..

eg.
$0100 holds $80
$01FF holds $32
$0200 holds $14

then the command

JMP ($01FF)

would load the program counter with $8032, instead of $1432

First time I saw it used was in some copy-protection code in the C64 version of Sim City.. It was some obfusication to screw up beginning crackers.. (it threw me for about 5 minutes..)

Ahh, those were the days :o)

Best Error Message Ever...

[Master_Ruthless]

I found in one of the early pre-PDC builds of Visual Studio.NET. You just got a simple message box with the following text:

"Dude- the C# compiler is out of memory. So out of memory that it can't even tell you what the error was!"

The buttons below were pretty cool too. One said "ok" and the other one said "lame!"

If you clicked the lame! button, you just got to fill out a little comment card, but the feature cracked me up the first couple times I saw it.

I know, it's a feature.

[Elwood P Dowd]

As far as I could tell when I was using Perl, running under strict mode would make it so that print() only worked with strings that ended in \n. I can't tell you how long that takes every beginning Perl programmer to figure out. Took me a good four hours.

My favorite bug in slashcode is that clicking "Parent" in my default story view always returns the default story view, not the parent of the post I'm clicking on. So I have to click on the post ID number, then click parent on the resulting page.

Re:From MSDN...

[cpeterso]

What's next - random() always returning 666 no matter what seed you use?

random() only returns 666 if you use a demon seed!

Hidden slashdot discussions

[mcc]

As others have noted, this isn't a bug, these are just the stories that the editors decided weren't important enough to warrant a full front-page thing. Funnily enough, these "section page only" articles tend to have much better and more insightful comments than the front page articles, because people only post there if they really care :)

Beyond that, though, what i liked was that used to, on slashdot, you could post to sid's that didn't exist. Like, you could go to http://slashdot.org/article.pl?sid=haiku, or something, and while there wouldn't be a story at the top of the page, you could post comments there, and the next person to go to http://slashdot.org/article.pl?sid=haiku would see that comment and could reply to it, until the comment reached a certain age and was automatically deleted. There used to be a whole bunch of these little "hidden" discussion areas littered all over slashdot that people would form entire little communities around them. Unfortunately, this was mostly used for troll groups to coordinate attacks. (K-9-something-inches or something? I don't remember.)

Unfortunately they seem to have removed this feature from slashdot :( Unless i'm just confused about how it's done, anyway. But it seems to be disabled, going to a non-existent sid now shows "Nothing for you to see here, move along".

There were some other really bizarre but fun slashdot bugs, like how there was some wierd twilight zone area at sid 0, or sid null (or something.. "slashdot.org/?sid=", i think was the url.. i can't remember. i think it was called "test discussion". or something) that you'd sometimes get dumped at if you clicked on the "parent" link in the preview of a post you were writing. Not always, just sometimes. The thing was though, there was some other bug that for some unfathomable reason would sometimes cause posts to get moved out of their correct threads, and into the null discussion, at random. And people wouldn't notice this. And so if you went to the test discussion, you'd just see hundreds and hundreds of random posts, totally irrelivant to each other or anything else, on totally random subjects. It was fun to go through this and try to guess what subjects the posts were on.

And then there was.. i barely even remember this one. There was a page i managed to get to a couple times-- i can't remember how, but there was a simple way to do it that would work every time-- that just said, "Here are some open discussions", and linked a bunch of articles. The Test Discussion was always near the top of this list. I'd expect that whatever this page is, it's gone now, but can anyone remember what this page was or how i would have gotten to it?

'Bug' in custom chip

[apuku]

I was trying to debug a CMOS standard-cell chip that I designed in the late 80's. The bug was elusive, only showing up occasionally and I'd written various test routines to ferret it out. I started to suspect it was something to do with the PCB layout, so I was cutting and pasting tracks. Suddenly all the test routines worked perfectly and I thought GOTCHA! My mind was almost blown when I realized that I had inadvertently cut the power trace to the chip - it was working perfectly when Vcc wasn't connected!

Of course, I eventually figured out that the original problem was ground bounce and that with Vcc disconnected, the chip was getting power through the protection diodes on the control lines and bus. The lower voltage was slowing down the edges and reducing the ground bounce so that it worked correctly. I eventually solved the problem with PCB layout changes and the chip started working with Vcc connected!

beat a-round the bush

[Mr Z]

There is no "proper" way to reduce the precision of a number under all circumstances. Each method of rounding or truncating 0.5 has its own pitfalls:

• Round-to-even, aka. banker's rounding. This is probably the best, since it distributes errors uniformally so as to not cause a long-term average bias. It's also very expensive to calculate as compared to the alternatives.
• Round (pseudo)randomly. Add an infintesimally small random or pseudo random bias to numbers that end in 0.5. This has the same bias properties as round-to-even, but with less predictability. If the biasing function is just a simple hash of the other bits of the number, though, then at least it's deterministic.
• Round-towards-zero. (I believe this is sometimes called "unbiased rounding".) For numbers uniformally distributed around zero, this form of rounding tends to also have no long-term average bias. The average magnitude is biased, though, towards smaller magnitudes.
• Round-towards-plus-infinity. (aka. "rounding up", or sometimes just "rounding".) This is the rounding they usually teach you in grade school -- round 0.5 up. (At least, that's what they taught me until I got to high-school.)
• Round-towards-minus-infinity. (aka. "rounding down" or "truncation".) This is what you get when you always round down. Right-shifting 2s complement numbers (with sign extend) typically gives you this form of rounding. One nice side effect is that the bias is uniform and so can be made to cancel in some cases elsewhere in your calculation. This technique has the advantage of being the cheapest -- you just throw away bits.

So, as you can see, there's no right way per se. It just depends on what you're doing.

--Joe

Re:beat a-round the bush

[krulgar]

The other strategy is to use "Arthur Andersen Rounding" which rounds all figures up to and including 3,800,000,000.00 to zero.

Re:Heisenbugs

[The_Shadows]

Well, that's only operating on the Heisenbug principle.

My favorite bugs aren't exactly reproducable ones. I favor Schrodinger's Bugs. When it comes down to it, it says that if you haven't seen the code, every line contains neither working code nor bugged code. Only when it's seen is the result known. Programs complied from such code are often called Beta tests.

In all seriousness, random libs *suck*

[edremy]

random() only returns 666 if you use a demon seed!

My favorite "bugs" are the truly horrible random number functions in almost every single language library on earth. They're usually linear congruential generators: fast, but utterly useless for any work that requires serious "randomness" such as Monte Carlo simulations. They have very short recurrence times, strong sequential correlation, etc.

Back in grad school, I had to substitute the Knuth ran3 routine for the supplied C library functions in both gcc and xlc since they were just awful.

Fast forward 8 years. I made the stupid assumption that since Java was a new language and that horrible problems with random number generators were well known that Sun would actually provide a decent RNG. Nope: just as badly flawed as the C one.

I suspect this is simply something to give up tilting at windmills about: random() is good enough for simple games and anyone doing real work knows to stay the hell away.

Try the Mersenne Twister

[Wraithlyn]

Check out the Mersenne Twister, it's beautiful. Here's a couple points from that page:

• Far longer period and far higher order of equidistribution than any other implemented generators. (It is proved that the period is 2^19937-1, and 623-dimensional equidistribution property is assured.)
  
• Fast generation. (Although it depends on the system, it is reported that MT is sometimes faster than the standard ANSI-C library in a system with pipeline and cache memory.)
  
• Efficient use of the memory. (The implemented C-code mt19937.c consumes only 624 words of working area.)
  

There are implementations in C, Java, PHP, Fortran, Excel (I assume VBA) and probably others.

I only have experience with the Java impl, and it is very good. There are two classes, MersenneTwister, which is a true descendant of java.util.Random, and there is also a MersenneTwisterFast class, which does NOT inherit from Random (same public methods, and identical algorithm though), but clocks in at about twice the speed, due to tricks like avoidance of synchronization, and method inlining and finalizing.