35. Debugging

Debugging refers to a process in software development whereby program analysts comb through computer code looking for “bugs” — the source of errors, flaws or security holes in the internal program instructions. Hardware development also goes through debugging to ensure compatibility with current hardware standards and interoperability between components that adhere to the same protocols. Additionally, debugging guarantees that hardware and software is backwards compatible, or will coexist with preexisting standards that might still be in use. As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. Debugging is the process of figuring out what the computer is doing and then getting it to do what you want it to do.

While in-house debugging can certainly rid software and hardware of many bugs, nothing replaces real-world testing. It is virtually impossible for an author or manufacturer to replicate every conceivable condition and system under which the hardware or software will be used. Many experienced IBM-PC users wait for a period of 12-36 months before migrating to a new operating system for this reason, such as making the switch from Windows™ XP™ to Windows Vista™. This gives the community time to identify any major security problems, bugs or other initial problems that might require debugging and patching. A debugger is a program designed to help you debug your program. It enables you to execute your program one line at a time and check the contents of variables as you go along. You can also modify the variables manually.DJGPP comes with a debugger named GDB. This is a command-line debugger, and I have never seen any need to work out how to use it. RHIDE, an Integrated Development Environment for DJGPP by Robert Hohne, provides an interface with GDB making it much easier to use.

Print debugging is the act of watching (live or recorded) trace statements, or print statements, that indicate the flow of execution of a process. Often the first step in debugging is to attempt reproduce the problem. This can be a non-trivial task, for example in case of parallel processes or some unusual software bugs. Also specific user environment and usage history can make it difficult to reproduce the problem. After the bug is reproduced, the input of the program needs to be simplified to make it easier to debug. For example, a bug in a compiler can make it crash when parsing some large source file. However, after simplification of the test case, only few lines from the original source file can be sufficient to reproduce the same crash. Such simplification can be made manually, using divide-and-conquer approach. The programmer will try to remove some parts of original test case and check if the problem still exists. When debugging the problem in GUI, the programmer will try to skip some user interaction from the original problem description and check if remaining actions are sufficient for bug to appear. To automate test case simplification, delta debugging methods can be used.

After the test case is sufficiently simplified, a programmer can use debugger to examine program states (values of variables, call stack) and track down the origin of the problem. Alternatively a tracing can be used. In simple case the tracing is just a few print statements, which print out the values of variables in certain points of program execution. Remote Debugging is the process of debugging a program running on a system different than the debugger. To start remote debugging, debugger connects to a remote system over a network. Once connected, debugger can control the execution of the program on the remote system and retrieve information about its state. Post-Mortem Debugging is the act of debugging the (core) dump of process. The dump of the process space may be obtained automatically by the system, or manually by the interactive user. Crash dumps (core dumps) are often generated after a process has terminated due to an unhandled exception.