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.

I was thinking about how two bugs could interact with one another. The only relationship I can think of is one bug being the cause of another.

What other interactions between multiple defects are common in everyday coding? What kinds of behaviors could result?

share|improve this question

closed as unclear what you're asking by Jim G., MichaelT, GlenH7, Robert Harvey, BЈовић Jul 10 '13 at 6:12

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

I smell a good question behind a half-baked phrasing. –  Doc Brown Jul 8 '13 at 12:10
There was a nice question on SO on different classes of bugs. Like the "Heisenbug" (disappears when you try to look at it). I can't find the link though :( –  Mike Brown Jul 8 '13 at 13:45
@DocBrown: I don't. Voting to close. –  Jim G. Jul 10 '13 at 0:01
@JimG - I agree with Doc. There are definable ways that multiple defects can interact, which manifest as different symptoms, and it's useful for a programmer to know what possible problems could be lurking behind a strange behavioral error. It wasn't asked very eloquently, but I think the question has merit. –  KeithS Jul 10 '13 at 1:05
show 3 more comments

5 Answers

  • Masking - As Uwe said, defective code may not produce an error because other code controlling the defect's execution may itself have a defect that causes the first defect not to execute when expected. Typically the most obvious bug is in the controlling code, and fixing that defect will expose the other. If the system appears to execute correctly, however, this masking can create "Higgs Bugsons" (a bug theorized to exist by code inspection but which does not appear when expected at runtime).

  • Offsetting - Two code components may both have defects which, in combination, perform offsetting operations to produce the correct behavior (at least in the tested scenarios). "Fixing" one observed defect in source code (possibly by noticing and correcting the implementation's differences from the abstract algorithm) will expose the other. Differs from masking in that the system usually behaves correctly as implemented, but will fail when a new "correct" implementation is swapped in. Can also be the source of "Higgs Bugsons".

  • Compounding - Two code components may have defects which cause the incorrect behavior, and resolving either one of the two will not correct the behavior; both bugs must be identified and corrected. Not knowing the other bug exists is a common cause of creating offsetting bugs, by "giving up" and building the unknown bug's observed error into the code that had the known defect.

  • Enabling - Related but different from compounding, two code components may each test perfectly in isolation, but the behavior of the two when combined is incorrect, and the actual "defect" isn't wholly inside either component. This is a common cause (the other main one is timing/concurrency issues) of "Heisenbugs", which can't be reliably pinpointed in an isolated environment with monitoring tools.

  • Randomizing - Somewhat like masking, a code component may have a defect that would be reliably reproducible in isolation once found (and thus relatively easily fixed), but is controlled by another component (possibly defective itself) that causes the bug to be observed in an apparently non-deterministic manner. A common cause of "Bugfoots" (bugs seen rarely by just one or two people at a time).

  • Derandomizing - The rough opposite of randomizing, a bug deeper in code that would normally be rare and apparently random is made obvious by another defect causing the code with the first defect to be executed in situations where it shouldn't. While this is often a gift in disguise to expose these rarer defects, a developer may often miss the defect in the code being executed, assuming the observed error stems solely from executing the wrong code in the tested situation, which can transform the deeper defect into a "Bugfoot".

  • Hyper-Corner - Two "corner-case" situations may cause minor errors (or be handled correctly) individually, but in tandem they cause a "synergistic" bug behavior that is different or far larger in scope or severity. Hyper-corners differ from simple compounding in that the individual corner cases may be well-handled, and that the combination isn't a simple sum of errors but can cause much more severe behavior (becoming a "Hindenbug" - a catastrophic, highly destructive bug with severe monetary or life safety consequences). Think Chernobyl; the result of a combination of failures in human decisions and mechanical design, any one of which would likely have been tolerated by the full system, said combination happened only once, and we're still dealing with the mess it left behind. I would propose the term "Chernobug" for this type of defect along similar lines.

  • Duct tape - A previous defect or other problem may have been "solved" in an incomplete or defective way, addressing the specific observed need and not causing observed regression, but exposing a new untested defect. AKA "technical debt", it is a common cause of "Jenga code" (change one small thing and the program falls apart), "Hooker code" ("goes down nightly"), "Hydras" (fix one bug and two more pop up in its place) and other systemic instabilities.

  • Scapegoating - A piece of code may execute correctly, but other code monitoring or depending on that code has a defect which will indicate that the correct code is defective. Attempts to "fix" the apparent source of the defect instead of the actual cause will result in compounding or offsetting.

  • Entropy sprinkler - A defect in code may be scattered to the four winds by other dependent code as a fine haze of "NKR" (Not Quite Right). Floating-point rounding error is a common example. The symptoms often indicate multiple independent bugs, and failure to probe deeply enough to find the true source may lead to offsetting and duct tape.

share|improve this answer
I would add that sometimes a particular bug may result from a poor understanding of a type of code and that poor understanding may be elsewhere. I'm thinking of things like failing to handle the case where a divisor turns out to be zero or someone who never handles nulls correctly. Each implementation may be a different formula or unrelated piece of code but the same fundamental misunderstanding of what to do is through the application. Sort of like Entropy sprinkler only the code isn't necessarily related except through the coder's misunderstanding of how things work. –  HLGEM Jul 8 '13 at 21:12
@HLGEM: Very correct, but this question was about the combination of two bugs producing a problem that might not be expected. The entropy sprinkler lies on the very fringe of that anyway, being a combination of a bug and dependent code (which may or may not have a defect) that causes many problems. I included it because I've seen it many times, and it can often appear to have multiple causes until you have the ability to trace many instances of error back to their true source. –  KeithS Jul 9 '13 at 16:01
add comment

Ever thought about masking bugs?

One bug can mask another bug.

E.g. you have class A with a bug. Now you write a second class B that accesses class A. You write the class B so tht it works correctly together with class A.

When you now fix the bug in class A it is possible that you will see a bug in class B that was there before but was masked by the bug in class A.

Then both bugs are related.

share|improve this answer
add comment

This seems like a very open-ended question and is likely designed as such. I can think of two more options:

  • they can be unrelated
  • one can cause the other to become visible without causing it
share|improve this answer
Another possibility is that there is a third bug that is causing them both –  Ismail Badawi Jul 8 '13 at 8:15
add comment

Just from top of my head:

  • They can interact in such a way that results in correct behavior or the whole thing.
  • One bug can cause the other. Eg. Fixing one will fix both. This is actually single bug that results in two (or multiple) different behaviors.
share|improve this answer
add comment

Often, a bug can be activated, thus causing an erroneous state of the software, but the service delivered is still correct because of fault tolerance, either deliberate or happening by chance.

Only a second, uncorrelated, bug may cause the error to propagate to the output of the software, resulting in a failure.

share|improve this answer
add comment

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