What was your longest time to fix a bug?

Question

Well yes i know this is an anecdotal question - and if you want to close, do it.

But i'm hunting one for 18 month now. Everytime when i think i have a reproduceable use case i have someone coming in telling me we have other things to do.

The longest "on session" time seems to be yesterday 2 full working day to track down a multithreading race condition that only appeared the first time after installation of the program - luckily this time it was reproduceable. So i had to created builds after builds, reseting a VMWare image about a feeled 23434 times.

Only reason why i did it was that i had no milestone for the next 45 days so i took my time.

But i wonder if other people or development groups had opened a bug hunting season for a single bug. I remember one company where i worked in the past they had a very nasty memory leaking bug in Java and offered a month salary for the guy who fixed it - but never allowed regular working time to track it down. I think this bug is still alive today - 8 years after i left the company.

Answer 1

Bug: Featuritis.

Description: The urge to add more functionality to your program, usually fueled by the thought that "I've been writing more code, so my software should do more stuff!"

Time Until Fixed: About half an hour. Just as soon as I add this option...

Answer 2

If I can not find a bug for a couple of hours, then go to my whiteboard and try to find the error there. Complex errors are usually the result of design defects.

Answer 3

I dealt with one mysterious intermittent bug that went on for about 3 years until another developer identified the problem and fixed it (see this answer). In my defense, the ultimate source of the problem turned out to be a bug in Microsoft's code for SqlCE replication, after I had repeatedly and forcefully dismissed this is a possible source of the problem.

Answer 4

I had a bug in an SPI driver that ended up taking over two months to find. I would fix what I thought was the problem only to have another problem pop up.

The actual bug was that when the DSP sent a packet, at a higher frequency, at times the packet would get corrupted within the SPI channel, so what the cpu got was bad data.

That was hard to troubleshoot as I finally had to prove on an oscilloscope that it was actually a hardware problem. We had to capture a packet that had the corrupted data and show that it wasn't software.

Answer 5

For a number of problems, that depends if you count the time I actually spent fixing it, or the time that a number of other people had already spent, when they thought they'd 'fixed' it.

Answer 6

I've got one unkilled for something like a decade.

The thing is I'm not totally sure it even exists. It's always only been seen in hindsight based on someone's memory. Some weeks back I thought I had a reproducible case--but when I was sent the relevant files I could not reproduce it and I found one of them was corrupt anyway.

I have also killed one of about that age that was NEVER reported, I ran into it looking into something else.