What was the most stupid bug you could not find for a long time?

Question

I was working on a project that missbehaved, for some reasons no exception was thrown even when it should have. Deep down I have found this kind of error handling:

try {
    m.invoke(parentObject, paramObj);
} catch (IllegalArgumentException e) {
    new CaseLibException(e);
} catch (IllegalAccessException e) {
    new CaseLibException(e);
} catch (InvocationTargetException e) {
    new CaseLibException(e);
}

My brain recognized that several exceptions were wrapped into another one, so that's not so bad. But I had to stumble over this code at least 3 times to see what's missing...

What is your most stupid bug you could not find?

Answer 1

Not actually initializing some stack variable near the start of main. The thing would get zeroed automatically, well almost always.

Answer 2

Most of my stupid bugs haven't been actual bugs. They have been bad data and my assumptions about that data.

I have spent hours trying to find a bug in code where there wasn't one - I was debugging an old piece of code or I assumed that my test data set was something... and it wasn't.

Answer 3

Once when I was doing some math programming related homework it took me a couple of hours to figure out I had a + somewhere where I needed a *.

Answer 4

In C/C++ (which I learned recently)

if (x = 0) {
...
}

Answer 5

Not sure if it was the most stupid, but the nastiest one I ever had was where I had written some access control routines that depended in part on time of day (so you could write rules like 'this can only be accessed on a workday during office hours').

I had finished the code and ran all my tests and everything worked fine. Then I went home, came in the next work day and ran all my tests and they failed. I couldn't for the life of me figure out why this had happened since the code and all the tests were completely unchanged.

Turned out that daylight savings time had kicked in, and my code didn't handle that.

Answer 6

I was writing a parser using flex/bison. A feature was constant folding optimization, i.e. replacing 20 + 2 with 22, however my parser was replacing it with 4.

As part of the lexer I had a symbol table. I used a linear search with strncpy to search for existing entries. However, for the length parameter in strncpy I used strlen on the string in the symbol table. Not a clever idea, because if the entry in the symbol table is smaller then the one being added it will incorrectly match. For example, adding "20" would match to "2" because only the first character is compared. Therefore when my parser looked up the symbol for "20" it got "2". I took me hours to figure out why my 20s were changing to 2s.

Answer 7

This isn't my bug but I was present for it. My Wife and I took a java class together when we were in college. She's in Anthropology and I'm in finance but somehow we ended up in java. I loved it.

She spent an entire evening trying to make a "damned program draw a stupid $%^&*( house on the screen" and just couldn't. Being stubborn, she resisted any of my assistance until her final moment of desperation (2, 3 am?). I took a quick look and notice she had used "O" (letter o) instead of "0" (zero) throughout.

She withdrew from the class the next day.

Personally, I have a few dumb mistakes that can be common. My favorites are:

dollar sign + function_name using the same iterate ($i) instead an already looping $i iterate loop the random "`" that happened SOMEWHERE because my hand slipped

Answer 8

I fixed a bug once where the application crashed every day at 6:12pm.

Turned out that someone had stored the number of seconds since the start of the day in a 16bit int.

Answer 9

When I was much less experienced with curly brace language, I once wrote something along the lines of:

if (expr);
    stmt;

It was in an embedded system, so my debugger and printf were powerless. It just made the audio sound bad. I put it down to poor performance and spent a day or so optimising it. A back of an envelope calculation would have shown that performance was not a problem.

From that day I always put my braces in. It makes me want to write in Python, if it wasn't for the rest of the language.

Answer 10

Why, I've never produced a bug in my life!

Answer 11

Long ago in my high school CS days, I implemented a binary tree in (I think) Turbo Pascal. One of the operations didn't quite handle its pointers correctly and ended up overwriting parts of the code segment (ah, the joys of DOS programming). Anyway, it always ended up overwriting all the debugging code I put in, making IF statements seemingly lie, print statements not happen, and the like, but all miraculously without crashing, and made it pretty much impossible to tell what was going on.

Eventually I ran it through an assembly-level debugger and caught the problem when the instructions started changing in the middle of the function...

Answer 12

I can't tell you the specific bug I've run into, but I can tell you involved at least one of the following:

• An assumption that something was working
• An assumption that data was correct
• A typo
• A = instead of ==
• Something I should have refactored

Actually that's a list of causes of all my bugs ;)

Answer 13

Once I wrote a function to parse a date-time string into another format. In it I had a switch/case statement which parses the month values, it looked like this:

case month of:
  01: return "Jan"; break;
  02: return "Feb"; break;

  ... etc ...

  09: return "Sep"; break;
  11: return "Nov"; break;
  12: return "Dec"; break;
end;

For some reason, I left out October...

Answer 14

Also, how can we forget the bugs introduced by the evil of COPY AND PASTE !!

Answer 15

for i = 0 to ( list.Length - 1 ) do
  begin
  DoSomething( 1 );
  end;

Try finding that on a crummy monitor with a tiny font at 3am! ;)

Answer 16

I once was debugging a program that was multithreaded, but where the multithreading could be disabled. The program would segfault randomly, but only with multithreading enabled. After trying to isolate every race condition possible, I realized that the only problem was that I was writing past an array bound. In single-threaded mode, the memory allocator was allocating memory predictably, such that the data at the address directly above this array was not needed anymore by the time it was overwritten, so the bug did not have any symptoms. In multithreaded mode, the data at these addresses was data owned by other threads.

Answer 17

Not my worst, but a recent example of ternary operator evil:

Had me stumped for a while why columnCSV was always empty:

foreach(Column column in Table.Columns)
{
    columnsCSV += string.IsNullOrEmpty(columnsCSV) ? "" : "," + column.Name;
}

Should have been

foreach(Column column in Table.Columns)
{
    columnsCSV += (string.IsNullOrEmpty(columnsCSV) ? "" : ",") + column.Name;
}

P.S. Please ignore the 'lack of StringBuilder' evil.

Answer 18

} and sometimes )

Answer 19

In the old days, when we had code on cards, I worked for three days, trying to figure out why my batch jobs weren't working. I finally was down to PRINT statements about every three lines, and I wasn't seeing ANY of them.

Then I realized there was a JCL error that was keeping my program from being loaded into the appropriate dataset (think "wasn't getting into the path") so I'd been running the same old image, over and over again, instead of the newly compiled one.

Answer 20

  I=1

That single line of Fortran simply wasn't working.

After several hours of fruitless debugging, I swallowed my pride and had a buddy step through the code with me.

Upon coming to that line, I said, "and now we increment the subscript."

"Huh?" says he.

That's when I realized I was reading my intent:

 I=I+1

instead of what I had written.

Remember that the next time you're stuck and can't figure out what's wrong.

Don't let your pride keep you from recruiting a second pair of eyes.

Answer 21

How's this for a bug that'll drive you crazy trying to figure out what's going on:

#if CONFIG_SETTING == 1
#define SOME_MACRO( x) doSomething( x);
#else
#define SOME_MAcRO( x) // don't do it in retail
#endif


void foo( int a, int b) 
{
    if (a < b) SOME_MACRO( a);

    alwaysCallThisFcn();

    // ...
}

So if CONFIG_SETTING is 1, foo() is compiled as:

void foo( int a, int b) 
{
    if (a < b) doSomething( a);; // note: the second 
                                 // semi-colon has no effect
    alwaysCallThisFcn();

    // ...
}

Otherwise, it's compiled as:

void foo( int a, int b) 
{
    if (a < b)
        alwaysCallThisFcn();   // now alwaysCallThisFcn() is 
                               //   called conditionally

    // ...
}