Date post: | 17-Jul-2015 |
Category: |
Documents |
Upload: | iama-marsian |
View: | 61 times |
Download: | 0 times |
DEFINITION
Debugging is a methodical process of finding and reducing the number of bugs, or defects, in acomputer program or a piece of electronic hardware, thusmaking it behave asexpected.
BUG
A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
REASONS FOR A BUG
• Syntactic ErrorsInput code is not legal. Caught by compiler (or other translation mechanism)
• Semantic ErrorsLegal code, but not what programmer intended. Not caught by compiler, because syntax is correct
• Algorithmic Errors Problem with the logic of the program. Program does what programmer intended, but it doesn't solve the right problem.
SYNTATIC ERRORS
Common Errors:• missing semicolon or brace• miss-spelled type in declaration
One mistake can cause an avalanche of errorsbecause compiler can't recover and gets confused
main () {int iint j;for (i = 0; i <= 10; i++) {j = i * 7;printf("%d x 7 = %d\n", i, j);
}}
MISSING SEMI-COLON
SEMANTIC ERRORS
Common Errors:• Missing braces to group statements together• Confusing assignment with equality• Wrong assumptions about operator precedence,
associativity• Wrong limits on for-loop counter• Uninitialized variablesmain () {int iint j;for (i = 0; i <= 10; i++) j = i * 7;printf("%d x 7 = %d\n", i, j);
}
MISSING BRACE,So printf() is mot a part of for
Algorithmic Errors
Design is wrong, so program does not solve the correct problem
Difficult to find• Program does what we intended• Problem might not show up until many
runs of program• Maybe difficult to fix• Have to redesign, may have large impact
on program code
DEBUGGING PROCESS
• TestingTo determine if a code contains errors.
• DebuggingTo locate the error and fix it.
• DocumentationTo improve maintainability of the code. Include sensible comments, good coding style and clear logic
Testing
Yes
Error?
Debug
• Unit testingTest of individual parts of an application – a single method, a single class, a group of classes, etc.
• Positive versus negative testingPositive testing – testing of functionality that we expect to work.Negative testing – testing cases we expect to fail, and handle these cases in some controlled way (example: catch handler for exception).
• Test automationRegression testing – re-running tests that have previously been passed whenever a change is made to the code.Write a test rig or a test harness.
• Modularization and interfacesProblem is broken into sub-problems and each sub-problem is tackled separately – divide-and-conquer.Such a process is called modularization.The modules are possibly implemented by different programmers, hence the need for well-defined interfaces.The signature of a method (its return type, name and parameter list) constitutes the interface. The body of the method (implementation) is hidden – abstraction.Good documentation (example: comment to describe what the method does) aids in understanding.
• Manual walkthroughsPencil-and-paper.Tracing the flow of control between classes and objects.Verbal walkthroughs
• Print statementsEasy to addProvide information: Which methods have been calledThe value of parametersThe order in which methods have been calledThe values of local variables and fields at strategic points
• Tips and techniquesStart off with a working algorithmIncremental coding/test earlySimplify the problemExplain the bug to someone elseFix bugs as you find themRecognize common bugs (such as using ‘=’ instead of ‘==’, using ‘==’ instead of equals( ), dereferencing null, etc.)Recompile everythingTest boundariesTest exceptional conditionsTake a break
DEBUGGER
A debugger or debugging tool is a computer program that is used to test and debug other programs (the "target" program).
Typically, debuggers offer a query processor, symbol resolver, expression interpreter, and debug support interface at its top level.
DEBUGGING TECHNIQUES
• Execution tracing-running the program-print-trace utilities-single stepping in debugger-hand simulation
• Interface checking-check procedure parameter number/type (if not enforced by compiler) and value-defensive programming: check inputs/results from other modules-documents assumptions about caller/callee relationships in modules, communication protocols, etc.
• Assertions: include range constraints or other information with data.
• Skipping code: comment out suspect code, then check if error remains.
• Other Techniques:--Disassembly (in context and with live data!)-Execution Tracing/Stack tracing-Symbol watches
DISASSEMBLY
• Most basic form of debugging• Translating machine code into
assembly instructions that are more easily understood by the user.
• Typically implementable as a simple lookup table
• No higher-level information (variable names, etc.)
• Relatively easy to implement.
EXECUTION TRACING
• Follows the program through the execution. Users can step through line-by-line, or use breakpoints.
• Typically allows for “watches” on –registers, memory locations, symbols
• Allows for tracing up the stack of runtime errors (back traces)
• Allows user to trace the causes of unexpected behavior and fix them
LIST OF DEBUGGERS
Some widely used debuggers are
• GNU Debugger (GDB)
• Intel Debugger (IDB)
• LLDB
• Microsoft Visual Studio Debugger
• Valgrind
• WinDbg
.
.
.
.
.
.