02-01-2013, 02:57 PM
Better Debugging via output Tracing and Callstak-Sensitive Slicing
Better Debugging via output Tracing.doc (Size: 2.61 MB / Downloads: 51)
INTRODUCTION
The software may crash because of two reasons
1. Segmentation fault
2. Produced bad output, and continues to execute
If the software is not crashed and producing bad output cannot be recognized easily. To identify the crash causing lines of code and to put the break points or point of failures manually is time consuming. To overcome these issues, there is a need of a software which can easily identifies the break points automatically
A single point of failure (SPOF) is a part of a system which, if it fails, will stop the entire system from working. They are undesirable in any system whose goal is high availability, be it a network, software application or other industrial system.
The assessment of a potentially single location of failure identifies the critical components of a complex system that would provoke a total systems failure in case of malfunction. Highly reliable systems may not rely on any such individual component
The importance of good debugging tools cannot be overemphasized. Average programmers may spend considerable amounts of their program development time debugging. Several tools are available to help them in this task, varying from hexadecimal dumps of program state at the time of failure to window- and mouse based interactive debuggers using bit-mapped displays. Most interactive debuggers provide breakpoints, traces, and some facilities to examine the program state as their main debugging aids. Unfortunately, these traditional mechanisms are often inadequate for the task of quickly isolating specific program faults.
One approach to address the above problem is to provide users more control over actions they may take when a breakpoint or a trace point is reached, and to provide them with explicit mechanisms to construct high-level abstractions by correlating the low-level events. In this paper, we propose a different approach based on a new debugging model. The importance of this model lies in the fact that each step in it can be largely automated, thus removing much of the tedium from the debugging process. It also provides a systematic approach to debugging, thus attempting to introduce an element of science into something that otherwise has largely been considered an art.
LITETURARE SURVEY
Debugging
Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware, thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another. There five steps in debugging:
1. Identify the Bug
2. Replicate the Bug
3. Understand the Bug
4. Fix the bug
5. Learn From the Bug
Identify the Bug
Debugging means removing bugs from programs. A bug is unexpected and undesirable behavior by a program. Occasionally there is a formal specification that the program is required to follow, in which case a bug is a failure to follow the spec. More frequently the program specification is informal, in which case people may disagree as to whether a particular program behavior is in fact a bug or not.
Replicate the Bug
The first step in fixing a bug is to replicate it. This means to recreate the undesirable behavior under controlled conditions. The goal is to find a precisely specified set of steps which demonstrate the bug.
In many cases this is straightforward. You run the program on a particular input, or you press a particular button on a particular dialog, and the bug occurs. In other cases, replication can be very difficult. It may require a lengthy series of steps, or, in an interactive program such as a game, it may require precise timing. In the worst cases, replication may be nearly impossible.
Understand the Bug
Once you are able to replicate the bug, you must figure out what causes it. This is generally the most time-consuming step. As a practicing programmer, you are probably familiar with the tool called a debugger. The name of this tool makes it seem like the tool of choice for debugging--it seems logical that in order to debug you would use a debugger. However, this is inaccurate. As I said initially, debugging means removing bugs from programs; while a debugger is a powerful tool, one thing it does not do is remove bugs. A better name for the tool would be "inspector".
In order to fix a bug, you must understand it. A debugger can sometimes help you understand a bug, but it is only one of several tools for that purpose. Only in certain specific circumstances should it be the first tool you reach for. In order to understand a bug in a program, you must have some understanding of the program. If you wrote the program, then you presumably understand it. If not, then you have more serious problems.
Locate the bug
The next step is to locate the bug in the program source code. There are two source code locations which you need to consider: the code which causes the visible incorrect behavior, and the code which is actually incorrect. It's fairly common for these to be the same pieces of code. However, it's also fairly common for these to be in different parts of the program. A typical example of this is when an error in one part of the program causes memory corruption which leads to visible bad behavior in a completely different part of the program. Do not let your eagerness to fix the bug mislead you into thinking that the code which directly causes the bad behavior is actually incorrect.
Ordinarily you must first find the code which causes the incorrect behavior. Knowing the incorrect behavior, and knowing how the source code is arranged, will often lead you quickly to the part of the program which is at fault. Sometimes a quick scan of the source code is enough to identify the problematic code.
Otherwise, narrowing down the bad behavior to a particular piece of code is where a debugger can be very useful. If you are lucky enough to have a core dump, a debugger can immediately identify the line which fails. Otherwise, judiciously setting breakpoints while replicating the bug can quickly hone in on the code you are after.
Modern debuggers, such as gdb, have powerful capabilities to make this process more manageable, such as conditional breakpoints, data watch points, ignoring breakpoints certain numbers of time, and support for executing simple code at breakpoints. These features are very useful when locating bad behavior in code which is executed many times, and only fails under particular circumstances. It's a good idea to learn the features which your debugger provides.
Fix the bug
The final step in the debugging process is, of course, to fix the bug. I won't discuss this step in detail, as fixing a bug is where you leave the debugging phase and return to programming. I'll just mention a couple of points.