Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If possible write how to avoid this kind of bug (besides testing, of course, please write a specific technique)

share|improve this question
show 2 more comments

closed as not constructive by gnat, Bart van Ingen Schenau, Kilian Foth, Jalayn, GlenH7 May 30 '13 at 14:58

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

16 Answers

up vote 38 down vote accepted

Here a list of Unusual software bugs exceptionally difficult to understand and repair:

  • Bohrbug - Manifests itself consistently under a well-defined (but possibly unknown) set of conditions

  • Mandelbug - Its causes are so complex that its behaviour appears chaotic or even non-deterministic.

  • Heisenbug - Disappears or alters its characteristics when an attempt is made to study it.

  • Schrödinbug - Manifests only after someone reading source code or using the program in an unusual way notices that it never should have worked in the first place, at which point the program promptly stops working for everybody until fixed.

  • Phase of the Moon bug - Manifests only on certain occacions in ways such as if it was dependent on the phase of the moon (thus these bugs are usually time and/or storage dependent).

  • Statistical bug - Can only be detected in aggregates and not in single runs of a section of code.

share|improve this answer
2  
@mskfisher: Done. –  gablin Oct 16 '10 at 9:01
show 2 more comments

The hardest bugs to find are exactly those bugs that you can't reproduce consistently. Could be from memory corruption, concurrency, or other things.

Annoying bugs but not as hard as the above include those that will happen on someone else's computer consistently but not yours.

share|improve this answer
show 2 more comments

The hardest bug to find is the one that doesn't exist. This typically happens when you have been given an inaccurate set of requirements by management, and users expect the software to do things it was never designed to do. You'll usually get a vague bug report about the feature not working or getting broken, and only with enough detective work do you find that it's working flawless according to the specs, which were totally wrong.

This is especially time-consuming if you've inherited code from other programmers, because you're not fully aware of what features the software does and does not support.

share|improve this answer
add comment

Bugs that aren't bugs but your fault. I.e.:

  • open a file, edit it
  • rename the file
  • use open editor to fix something and save
  • rerun and notice the error is still there
  • recheck you logic, have a coffee break, cry, delete everything except "print 'Hello World'"
  • notice you never opened the renamed file

(I hope I'm not the only person who is sometimes a little absent-minded)

share|improve this answer
1  
Yeah, this happens. It's sometimes even caused by tools. Today I had two versions of the same file in my Flash Builder project (by accident) and while the compiler would use version A, Ctrl-Clicking on the class name in another file would open version B in the editor. –  Bart van Heukelom Sep 17 '10 at 17:33
add comment

Bugs related to the current date.

I once heard a story about a bug that couldn't be reproduced but it kept comming back. Eventualy they found out, the bug only occured in the last three months of the year, on days 10-31 and on a wednesday. Those dates: Wednesday xx-xx where just one character to big for the buffer overwriting other data.

share|improve this answer
2  
This is actually a good example of why global mutable state (clock) is evil and time-related data should be injected as a dependency as much as possible. This makes it easy to unit-test the code for correctness for a large amount of dates/times. –  Magnus Wolffelt Dec 1 '10 at 11:06
2  
Three words. Daylight Savings Time. –  fennec Dec 13 '10 at 14:46
add comment

The ones that arise because of inadequate requirements gathering and verification during the specification phase.

Years ago I worked on a CAD package that had been extended to help one user design liquid crystal displays. They designed the anode and cathode on separate layers and then performed a logical AND on the boundaries to see what shapes they'd get when the current was applied.

We had a long running problem where they'd report that the code failed but we couldn't reproduce the bug. Eventually we found the cause. They were using a scaling factor when drawing the shapes which led to rounding errors (we were using floating point values for the calculations - this was in FORTRAN back in the 1980s). Once we realised this we could reproduce the problem and fix it (by converting the routines to double precision).

Had the requirements been properly checked we would have never had this problem.

share|improve this answer
add comment

Bugs introduced by the compiler.

Way back I worked for a company that used an in-house compiled language and bugs would show up in "production" code but would work just fine if compiled in "debug" mode.

share|improve this answer
1  
These can sometimes be caused by extra logging or other debug stuff slowing it down. –  Hugo Sep 13 '11 at 19:01
show 1 more comment

Inconsistent bugs in someone else's API, coupled with limited debugging info.

I was working on a realtime component of a massive distributed system (witten in c). All the components were kept in strict sync by a time daemon. My component passed all its testing, but once the release build was deployed at the customer site, it started crashing at seemingly random times. The only debug info I had was the core dump and a limited event log. The core dump indicated that it was dereferencing a null pointer that seemingly couldn't possibly be null.

The debug strategy involved trying to piece together history from the core and the code, adding additional events to the log, and waiting for the crash to happen again. Early on I started to suspect that the only possible way that particular pointer could end up null was if a certain call to the GetTime() function returned a time earlier than the previous call, but the core utilities developer insisited that was impossible. So I spent 3 days adding more logging, tracing through code paths, etc. Then, finally I got a log which caught the time daemon in the act of subtracting a millisecond from the running clock. The worst part is the other guy never apologized.

share|improve this answer
add comment

Firmware bugs that you only get memory dumps to debug with and take days of continual runtime to reproduce.

share|improve this answer
add comment

The bug you can't reproduce.

(Extra pain points if someone else swears the bug is there, but never when you're around.)

If you can't reproduce it, how do you know what to fix? If you try to fix it, how do you know if you've succeeded?

These aren't impossible, just painful: do lots of research, lots of reading code, lots of deciphering logs (hopefully), lots of conjecture, until you come up with a working theory. Then you need a way to test the theory, which sometimes can take a fair bit of creativity.

One of my early examples was back at the dawn of the web, I had been with a company for a couple months, and our ticket purchase system started crashing every 2-3 days. We could find nothing that triggered it directly. Finally I tracked a memory leak (by reading code, IIRC) which meant the app would crash every so many transactions done via the website. It had never been a problem before, as the webapp would usually be restarted (for whatever reason) before the leaked memory could pile up. Once sales picked up, we weren't recycling often enough, and kaboom.

The most recent, and a bit minor example, was this week: a user-acceptance tester announced that IE8 was throwing Javascript errors on one of our pages. None of us could reproduce it. ?!?!? Turned out to only happen in IE8 with Developer Tools enabled and a certain compatibility mode selected -- which I happened upon myself, the tester didn't know this.

share|improve this answer
show 2 more comments

The one you haven't found yet.

share|improve this answer
add comment

In general, concurrency-dependend bugs, e.g. race conditions, can be pretty hard to find in testing and hard track down after they appear in production.

share|improve this answer
add comment

Bugs which depend on digitization of analog input are some of the most hardest to find, especially when the analog input is from an RF subsystem; the RF itself is difficult to reproduce even with expensive test equipment and the data pattern often can't be measured or reproduced in order to feed it into the software in a simulation environment. These bugs are a multiplex of "data pattern bug" plus "time of day bug" plus "external setup bug" plus "cosmic ray bug". RF engineering in itself is often known as black magic; then interface it to a D/A for software processing and all bets may be off..

GPS projects for example might depend on the relative positions of 12+ satellites in the sky; try reproducing that!

The method for solving these bugs typically includes avoiding them in the first place, with a lot of simulation across many data sets. Often these data sets attempt to create the worst-case data (combinations of outliers) to stress the software.

For example Speech or Audio processing software developers have huge data sets which are run through the algorithms to detect data pattern errors in the algorithms.

share|improve this answer
add comment

The hardest bug to find is that of your compiler or hardware--when something you write a correct program for is malfunctioning.

share|improve this answer
3  
However, I've seen developers blame bugs on the compiler way more often than I've seen a legitimate compiler bug. –  AShelly Sep 10 '10 at 15:02
add comment

I think it depends on the type of application, a low level C or asm is going to have a different "hard" bug compared to a web application running php and javascript.

Inconsistency will be a hard one though, when it appears to happen sometimes but not other times.

share|improve this answer
show 1 more comment

Copy-paste bugs

I know - these are not "the hardest", but significant too.

share|improve this answer
show 2 more comments

Not the answer you're looking for? Browse other questions tagged or ask your own question.