Introduction to Debugging? What strategies include debugging?

When the software testing is successfully done, the next step is debugging. Debugging is the process of removing the error that has been uncovered during the testing process. Debugging process starts with the execution of a test case. The results that are attained are assessed and the actual and expected values are compared. Debugging is the process that matches symptom with the cause.

In debugging process, there is a possibility of two outcomes:
- cause is found and corrected.
- cause is not found

Debugging sounds difficult and here are some reasons why it is so:
- The cause and symptom may be located remotely.
- Sometimes when some other error is corrected, the symptom disappear.
- Human error can cause a symptom.
- Timing problem can cause a symptom.
- Non errors can cause symptoms.
- Symptoms can be intermittent.
- There is a possibility that causes are distributed across different tasks running on different processors.

Debugging strategy includes finding and correcting the cause of software error by the use of three strategies:
- Brute force uses the philosophy of let the computer find the error. Memory dumps are taken, run-time traces are invoked and program is loaded with output statements.
- Backtracking is the process which starts at the site where symptom is uncovered, source code is traced backward until cause is found.
- In cause elimination, cause hypothesis is devised and data is used to prove or disprove the hypothesis. On the other hand, list of possible causes is developed and tests are conducted to eliminate each.

Overview of Race Conditions in Operating Systems

A race condition happens when a system depends on something being done outside of its control before the system reaches a point where it needs to use the results of that something, and there's no way to guarantee that that something will actually be finished when the system needs it.
For example, suppose there's a person who runs a program every morning that prints letters that have been queued throughout the previous day. There's another person in another department who runs a program that queues a letter, and then offers to let the person modify it while it's sitting in the printing queue. If the person runs this program too early in the day (before the printing program gets run), they're essentially in a "race" to finish their work before the printing program runs.

Symptoms Of Race Condition :

The most common symptom of a race condition is unpredictable values of variables that are shared between multiple threads. This results from the unpredictability of the order in which the threads execute. Sometime one thread wins, and sometime the other thread wins. At other times, execution works correctly. Also, if each thread is executed separately, the variable value behaves correctly.
While many different devices are configured to allow multitasking, there is still an internal process that creates a hierarchy of functions. In order for certain functions to take place, other functions must occur beforehand. While the end user perceives that all the functions may appear to be taking place at the same time, this is not necessarily the case.
One common example of a race condition has to do with the processing of data. If a system receives commands to read existing data while writing new data, this can lead to a conflict that causes the system to shut down in some manner. The system may display some type of error message if the amount of data being processed placed an undue strain on available resources, or the system may simply shut down. When this happens, it is usually a good idea to reboot the system and begin the sequence again. If the amount of data being processed is considerable, it may be better to allow the assimilation of the new data to be completed before attempting to read any of the currently stored data.