English subtitles

← Bug Categories - Software Debugging

Get Embed Code
2 Languages

Showing Revision 3 created 05/24/2016 by Udacity Robot.

  1. Welcome to the 5th unit in our debugging course titled Reproducing Failures.
  2. In the past units we have seen a number of techniques to systematically hand down
  3. a failure cause by following back dependencies and applying the scientific method
  4. to choose between various possible origins until we find the defect.
  5. So far, however, we have assumed that the program fails in the lab
  6. and that somehow we would be able to actually access these earlier states
  7. or at least run appropriate experiments
  8. where we would be able to gather additional.
  9. Contrast this with a program failing in the field where all we know is that the program failed
  10. plus possibly a few hints from the execution,
  11. but all-in-all only a spottier record compared to what you get in the lab.
  12. This is where reproduction comes into play.
  13. You have to reproduce the failing run from the field in the lab
  14. such that you can actually do the debugging. Why do you need to do that?
  15. We need to be able to observe the run,
  16. because once we have reproduced a failure locally,
  17. we can observe and experiment at will.
  18. This, of course, is invaluable for isolating the defect.
  19. Second, we need to be able to check the fix.
  20. Only if we can reproduce a bug can we be sure that we have actually fixed it,
  21. namely, if the failure no longer occurs.
  22. Reproducing a bug can be way harder than fixing the bug.
  23. In programmer's jargon, bug's fall into four categories.
  24. First, there is the Bohr bug from Bohr's model of the atom.
  25. This is a repeatable bug that many manifests reliably
  26. under a possibly unknown but well-defined set of conditions.
  27. Next category is a Heisenbug from Heisenburg's uncertainty principle in quantum physics.
  28. This is a bug that disappears or alters its behavior when one attempts to probe
  29. or isolate it.
  30. The next one is the Mandelbug, coming from the Mandelbrot set.
  31. This is a bug whose underlying causes are so complex and obscure
  32. as to make its behavior appear chaotic or even nondeterministic.
  33. And last but not least there is the Schrödinbug,
  34. which is MIT jargon coming from Schrödinger's cat thought experiment in quantum physics.
  35. You know--the situation in which you have a cat in a box,
  36. which may be dead or which may be alive, but you don't know until you open the box.
  37. This is a bug in a program that doesn't manifest until someone who reads the source
  38. or who uses the program in an unusual way notices that the program never should have worked,
  39. at which point the program promptly stops working for everybody until it is fixed.
  40. All these bug categories refer to various levels of difficulty as it comes to reproducing the bugs.
  41. Here is an example of a bug that was hard to reproduce that I once encountered.
  42. I had a C program that crashed all the time.
  43. In an extremely simplified version this is what it looks like.
  44. If I ran this program normally, it would crash.
  45. The assertion would fail.
  46. If I ran it in a debugger, however, it worked just fine.