Debugging

Debugging
• Definition: Debugging is the process of detecting and removing of existing and potential errors (also called
as ‘bugs’) in a software code that can cause it to behave unexpectedly or crash. To prevent incorrect
operation of a software or system, debugging is used to find and resolve bugs or defects. When various
subsystems or modules are tightly coupled, debugging becomes harder as any change in one module may
cause more bugs to appear in another. Sometimes it takes more time to debug a program than to code it.

Description: To debug a program, user has to start with a problem, isolate the source code of the problem,
and then fix it. A user of a program must know how to fix the problem as knowledge about problem
analysis is expected. When the bug is fixed, then the software is ready to use. Debugging tools (called
debuggers) are used to identify coding errors at various development stages. They are used to reproduce
the conditions in which error has occurred, then examine the program state at that time and locate the
cause. Programmers can trace the program execution step-by-step by evaluating the value of variables and
stop the execution wherever required to get the value of variables or reset the program variables. Some
programming language packages provide a debugger for checking the code for errors while it is being
written at run time.
Approaches to debug the Software
Applications
• 1) Brute Force Method: This method is most common and least efficient for isolating the cause of a software error.
We apply this method when all else fail. In this method, a printout of all registers and relevant memory locations is
obtained and studied. All dumps should be well documented and retained for possible use on subsequent problems.

• 2) Back Tracking Method: It is a quite popular approach of debugging which is used effectively in case of small
applications. The process starts from the site where a particular symptom gets detected, from there on backward
tracing is done across the entire source code till we are able to lay our hands on the site being the cause.
Unfortunately, as the number of source lines increases, the number of potential backward paths may become
unmanageably large.

• 3) Cause Elimination: The third approach to debugging, cause elimination, is manifested by induction or deduction
and introduces the concept of binary partitioning. This approach is also called induction and deduction. Data related
to the error occurrence are organized to isolate potential causes. A “cause hypothesis” is devised and the data are
used to prove or disprove the hypothesis. Alternatively, a list of all possible causes is developed and tests are
conducted to eliminated each. If initial tests indicate that a particular cause hypothesis shows promise, the data are
refined in an attempt to isolate the bug.
Debugging Methods
• Print/Trace Debugging - watching the flow of execution after
adding print statements to the original code
• Remote Debugging - connect to a remote system with a
debugger, monitor the execution and state
• Post Mortem Debugging - analysis of a memory dump from a
program that has crashed
• Profiling - not debugging per se, but a useful technique for analysing a
running program to look for issues
Lesser Known (?) Debugging Methods
• Rubber Ducking - explaining your problem to someone else. Stating
the problem aloud in order to work it out.
• Failfirst - Write a unit test that exposes the failure, correct the
code and make it pass
• Saff Squeeze - Write a system test, inline code, write test, repeat
until fixed
• Chaos Monkey - AWS Netflix approach - randomly kill and test
areas. Fail consistently to test fault tolerant software.
Eclipse Debugging 1
• Set breakpoints in the code
• Step into, over, return
• Watches - display a variable value
• Hit counts
• Setting an exception breakpoint
• Setting a method breakpoint
Eclipse Debugging 2
• Class load breakpoint
• Using display after a breakpoint has been hit
• Attaching a remote debugger via a JDB agent
Bug Taxonomies and Bug Types
• There are ways to categorise bugs... lots of taxonomies available from
research literature
• Some bug types include:
●Bohrbug - bug that manifests itself consistently
under a set of conditions
●Heisenbug - bug that alters its' characteristics when studied
Debugging Rules...
• 1. Understand the system
• 2. Make it fail
• 3. Quit thinking and look
• 4. Divide and Conquer
• 5. Change one thing at a time
• 6. Keep an audit trail
• 7. Check the plug
• 8. Get a fresh view
• 9. If you didn't fix it, it aint fixed
• Debugging - A Simple Method
• a) Start
• b) Construct a Hypothesis
• c) Construct an Experiment
• d) Hypothesis Proved? - goto b)
• Need more evidence? - goto c)
• Stop
Understanding the System
• Know the fundamentals of the system
• Understand the frameworks involved
• Read the API's and communication interfaces
• Know your tools
• Understand what each module of the system does
Make it Fail
• Start at the beginning
• Automate the failure
• No detail is insignificant
• Intermittent failures?
• Isolate the failure
• Build debugging tools and test harnesses
3. Quit thinking and look
• Gather the low level details and "see" the failure
• Understand the context of the bug
• Design instrumentation in:
●Runtime statistics
●Status messages
●Debug logging - be descriptive!!!
●Deployment time environment checks
• Hypothesize and test
Divide and Conquer
• Narrow the search down, software AND
• hardware. Successive approximation.
• Start at the bad end (e.g. the error log) and work
• your way up the chain looking at the various
• points on the way
• Fix the bugs you know about - fixing one could
• fix the other
Change one thing at a time

• Compare with a good one !

• Use a rifle not a shotgun
• What's changed recently, it used to work!
• Separate environment and product
Keep an audit trail
• Keep a day book of what you did
• During debugging write down...
1.What you did...
2.In what order...
3.And what happened!
• Be specific and consistent
• Correlate symptoms with others
• Version control and change logs are great for
• determining an audit trail of what's changed
Check the plug
• Question your assumptions
Get a Fresh View
• Get another viewpoint on the solution
• Talk to somebody about the problem
• Ask an expert:
• ●Email the author
• ●Check the forums
• ●Subscribe to the mailing list
• Make sure you report symptoms not theories
If you didn't fix it, it aint fixed!

• The most important lesson by far...

• ●Fix the root cause
• ●Make sure it can't possibly happen again
• ●Fix the process at fault
• "We didn't see an issue until we deployed into the production
• environment"
• = Deploy early and deploy often
Preventing Bugs
• Debugging is hard and expensive in terms of fixing
• the bug, testing it and re-deploying it...
• We can try and prevent bugs with:
●Code Review
●Defensive Programming
●Precondition, post condition and invariant checking
●Assertions
END