Got a YouTube account?

New: enable viewer-created translations and captions on your YouTube channel!

English subtitles

← Capturing - Software Debugging

Get Embed Code
3 Languages

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

  1. If a program fails in the field, rather than in the lab,
  2. this makes reproduction hard at first
  3. because you lack all the data you might need to do efficient debugging.
  4. However, having programs that execute in the field can actually also ease debugging.
  5. The basic idea is to exploit the many runs that are out there in the field.
  6. Suppose you have a number of runs, hopefully few, that fail
  7. and a number of runs, hopefully many, that pass. Or that don't fail.
  8. What you could look for is features of the execution
  9. that statistically correlate with failure.
  10. One such feature could be the execution of individual parts of the program.
  11. If you knew, for instance, that in all the nonfailing runs
  12. a specific function is never called,
  13. whereas the same function is always called in all the failing runs,
  14. and this information goes to you,
  15. of course the first thing you would do is to look at the function, F,
  16. in order to see what is it that could possibly go wrong in here.
  17. Instead of F, you could also come up with other execution features.
  18. For instance, this could be a specific line, or a specific return value,
  19. or a specific variable value.
  20. All of these features could possibly correlate with success or failure
  21. and thus provide important hints when it comes to the debugging.
  22. To get this to work, we need to collect these execution features.
  23. And we'll start with executed lines
  24. because this is plain and simple coverage.
  25. The idea, again, is to use a tracing function,
  26. and the tracing function would record for every single line in the file,
  27. whether it has been reached.
  28. So we have this global coverage variable and if we reach a new line,
  29. we extract the file name and the line number.
  30. And what we now do, if we do have the file name and the line number,
  31. is we check whether we've seen the file name before,
  32. and if we haven't, we create a new empty set.
  33. Then we add the line number to the set we found for this file name.
  34. Here again we set the tracer, and now we simply invoke this on a simple text
  35. without HTML markup.
  36. Let's see which lines are actually covered.
  37. Click on run, and here's the set.
  38. Lines 4, 5, 6, 8, 9, and so on,
  39. are being covered in here.
  40. Let's go and mark these lines, which are covered here in the code.
  41. There's line 4, 5, 6, 8, 9, 11, 13, 15, 16, and 18.
  42. The lines that are not covered are line 10, line 12, and line 14.
  43. That is all the lines that would set tag to specific values,
  44. or set quote to specific values.
  45. Since the result of passing some text without HTML markup is actually correct,
  46. we could now deduce that maybe we should come up with tests
  47. that check for these lines which we haven't covered yet,
  48. and see whether these fail, and then we could find out
  49. that errors would actually be related to the execution of these lines.
  50. But first, let's come up with an automatic mechanism
  51. to produce this markup; that is, whether a line is executed or not.
  52. The idea is to produce the program as output
  53. and prefix every single line with a star if it has been executed
  54. and with a blank if not.
  55. So we need to turn this set into the code prefixed with stars or not.
  56. Here is a starting point.
  57. Since we already have the file name, we can actually open the file name
  58. and read its context as an array of lines.
  59. Let's see whether this works.
  60. Indeed, what we get is a list of the individual lines in the program.