CS 2422: Software Debugging


Class 2

Course matters

Website: https://sites.google.com/ashoka.edu.in/cs2422/

SH office hours: Thursdays 6-7pm, AC04-723 (or Zoom)

AS office hours: Wednesdays 5-6PM (AC04-WS708)

SD office hours: Monday 6-7PM (AC04-WS708)

Reading assignment due tomorrow before class

Bug log

Do gather interesting/subtle examples

Do gather non-trivial bugs (on which you spend say, > 5 minutes)

Do gather bugs that you did not fix, but worked around or gave up on

Develop and refine your tagging system as you go along

Keep a pointer to the code/issue if possible

Bug log

Don't gather software installation problems (Windows, Wordpress, packages...) Prefer code level bugs.

Don't gather RFEs

Don't gather simple fixes like color or message change

Don't dredge up reports from the ancient past (unless they are very interesting)

A bit of history

How did the term bug originate?

Grace Hopper

Early computer pioneer

Got a Ph.D. from Yale in Math in 1934

Got a job with the Navy and was sent to program Mark-1 computer at Harvard


https://www.youtube.com/watch?v=oE2uls6iIEU
The first step is an intuition—and comes with a burst, then difficulties arise. This thing gives out and then that–“Bugs,” as such little faults and difficulties are called, show themselves.

T. A. Edison, November 13, 1878

Rutgers University Archives/Thomas Edison National Historical Park

Terminology

"Bug" is probably a bad term. ("A bug has crept in", as if on its own)

"Defect" and "Fault" are often used for hardware (or low level system) error

"Flaw", "Error", "Issue", "Failure", "Smell",...

Some people use the word infection (I don't like it.)

We'll just generically refer to bugs...

"In the meantime, I had another linguistic shock: I became a member of the ACM, shortly before its Communications started to appear. Prior to that I had hardly had any exposure to the foreign literature. What I then read was written in a way so totally different from what I, in relative isolation, had acquired as my own habit, that I was absolutely flabbergasted. The heavily anthropomorphic terminology was totally new for me, and hardly compatible with my cultural roots; so was the animism betrayed by the term "bug": we had never called a bug a bug, we had always called it an error."

- My Hopes for Computer Science, E.W. Dijkstra (4th ICSE, 1979)
"We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error)."
- On the cruelty of really teaching computing science, E.W. Dijkstra, 1988

Six Stages of Debugging

That can't happen.

That doesn't happen on my machine.

That shouldn't happen.

Why does that happen?

Oh, I see.

How did that ever work?

Original source (?)

Bug lifecycle

Bug/Issue tracking tools

e.g. Bugzilla, github, trac, etc.

Slightly overlap with project management tools

Issue source could be internal tester or external user

Assigned to and evaluated by a developer

Captures long-term record of bugs... much better than email

Bug lifecycle

Some special situations

Wontfix

Duplicate

Unreproducible

Reopened

Fixed, waiting for test

RFE (Request for Enhancement)

ECO (Engineering Change Order)

How to report a bug?

Provide enough information to reproduce

Be specific about the environment - OS, version, etc.

Simplify to the extent possible

Detail, to the extent possible (e.g. error messages, stack traces, what the user was doing, and other context)

Core dumps (memory state at program crash)

Search for the error message

Social Issues

Submitter and developer may not be known to each other

Very different conceptual models of the software

Maintain courtesy and trust

Don't fingerpoint, avoid typecasting people

Developer should always thank the person who found the bug

Developer should never close a bug