Tutorial: Debugging ECE250 Projects - University of Waterloo

0 downloads 78 Views 1MB Size Report
Feb 28, 2014 - correct result. For example, Figure 1 shows the sum after two pushes. Hence, there might be an error in S
Tutorial: Debugging ECE250 Projects Vajihollah Montaghami University of Waterloo

Douglas W. Harder University of Waterloo

February 28, 2014 Abstract In this tutorial you will learn what are bugs and how one can get rid of them using debugging tools, called debuggers. The GNU Project Debugger and Visual Studio debugger are two common tools that you can use them to systematically debug your projects implemented in C++.

1

Introduction

Developing error-free software is very hard. The way we are developing programs causes many errors resulting in an intended functionalities. The word error, or bug, covers a broad range of meanings from incorrect program code to incorrect program execution [1]. An incorrect program code happens due to a syntax error and can be detected and reported by the compilers. In the lab 0, you learned how to remove a syntax error from your program. A program with an incorrect execution, or logical error, is successfully compiled and run, but produces erroneous output during the execution. Logical errors are subtle and generally hard to be detected as a faulty program may behave well for the most inputs, but misbehaves in a rare and particular case. Eliminating errors, or debugging, consists of three activities: a) localizing the program statement that cause the problem; b) understanding the root of the problem; and c) fixing the problem. One can intuitively approach these activities or follow a systematic method. Using a systematic method, you do not require to be an expert or have a priori knowledge. In the systematic approach, one first observes the input/output of the system causing the failure. Then, he invents a hypothesis to understand what part of the program is exactly making the error. Based on the hypothesis, he makes a prediction. By running experiments, he tests the consistency between the hypothesis and predication. If the experiments do not satisfy the predication, the hypothesis has to be changed. Otherwise, the hypothesis is refined. The last step is repeated until the hypothesis cannot be refined any more. An illustrative example is provided in Section 1.1.

1

1.1

Example

We elaborate the systematic debugging approach by a concrete example implementing a stack. The program is given in Section 3 including the Stack class plus a main function providing an interactive console interface to play with an instance of Stack. If you run the given main function in Section 3, and test Figure 1: A run for testing stack class in section 1.1.

it by entering a number of pushes and asking for the ‘sum’, you will see an in correct result. For example, Figure 1 shows the sum after two pushes. Hence, there might be an error in Stack class that has to be resolved. Since the code was compiled perfectly, syntax error is not plausible and the error has to be logical. We start debugging the logical error by proposing hypothesis 1. Hypothesis 1. Since the sum function returns incorrect value, it might be implemented inaccurately. Predication sum does not consider all the elements in the stack. The iterators bound in the sum function is not adjusted correctly. Experiment To evaluate the predication, we can look at the code and see the iterator in the sum function is exactly similar to one in the operator command ; if ( " sum " == command ){ cout value ; try { stack . push ( value ); } catch ( overflow of ){ cout