WHAT IS DEBUGGING

In?computer programming?and?software development,?debugging?is the process of finding and resolving?bugs?(defects or problems that prevent correct operation) within?computer programs,?software, or?systems.

Debugging tactics can involve?interactive?debugging,?control flow?analysis,?unit testing,?integration testing,?log file analysis, monitoring at the?application?or?system?level,?memory dumps, and?profiling. Many programming languages and software development tools also offer programs to aid in debugging, known as?debuggers.

Etymology[edit]

See also:?Software bug §?History

A computer log entry from the Mark?II, with a moth taped to the page

The terms "bug" and "debugging" are popularly attributed to?Admiral Grace Hopper?in the 1940s.[1]?While she was working on a?Mark II?computer at Harvard University, her associates discovered a moth stuck in a relay and thereby impeding operation, whereupon she remarked that they were "debugging" the system. However, the term "bug", in the sense of "technical error", dates back at least to 1878 and?Thomas Edison?who describes the "little faults and difficulties" of mechanical engineering as "Bugs".

Similarly, the term "debugging" seems to have been used as a term in aeronautics before entering the world of computers. In an interview Grace Hopper remarked that she was not coining the term.[citation needed]?The moth fit the already existing terminology, so it was saved. A letter from?J. Robert Oppenheimer?(director of the WWII atomic bomb?Manhattan Project?at Los Alamos, New Mexico) used the term in a letter to Dr.?Ernest Lawrence?at UC Berkeley, dated October 27, 1944,[2]?regarding the recruitment of additional technical staff.

The?Oxford English Dictionary?entry for "debug" quotes the term "debugging" used in reference to airplane engine testing in a 1945 article in the Journal of the Royal Aeronautical Society. An article in "Airforce" (June 1945 p.?50) also refers to debugging, this time of aircraft cameras. Hopper's?bug?was found on September 9, 1947. Computer programmers did not adopt the term until the early 1950s. The seminal article by Gill[3]?in 1951 is the earliest in-depth discussion of programming errors, but it does not use the term "bug" or "debugging". In the?ACM's digital library, the term "debugging" is first used in three papers from 1952 ACM National Meetings.[4][5][6]?Two of the three use the term in quotation marks. By 1963 "debugging" was a common-enough term to be mentioned in passing without explanation on page 1 of the?CTSS?manual.[7]

Scope[edit]

As software and electronic systems have become generally more complex, the various common debugging techniques have expanded with more methods to detect anomalies, assess impact, and schedule?software patches?or full updates to a system. The words "anomaly" and "discrepancy" can be used, as being?more neutral terms, to avoid the words "error" and "defect" or "bug" where there might be an implication that all so-called?errors,?defects?or?bugs?must be fixed (at all costs). Instead, an?impact assessment?can be made to determine if changes to remove an?anomaly?(or?discrepancy) would be cost-effective for the system, or perhaps a scheduled new release might render the change(s) unnecessary. Not all issues are?safety-critical?or?mission-critical?in a system. Also, it is important to avoid the situation where a change might be more upsetting to users, long-term, than living with the known problem(s) (where the "cure would be worse than the disease"). Basing decisions of the acceptability of some anomalies can avoid a culture of a "zero-defects" mandate, where people might be tempted to deny the existence of problems so that the result would appear as zero?defects. Considering the collateral issues, such as the cost-versus-benefit impact assessment, then broader debugging techniques will expand to determine the frequency of anomalies (how often the same "bugs" occur) to help assess their impact to the overall system.

Tools[edit]

Main article:?Debugger

Debugging on video game consoles is usually done with special hardware such as this?Xbox?debug unit intended for developers.

Debugging ranges in complexity from fixing simple errors to performing lengthy and tiresome tasks of data collection, analysis, and scheduling updates. The debugging skill of the programmer can be a major factor in the ability to debug a problem, but the difficulty of software debugging varies greatly with the complexity of the system, and also depends, to some extent, on the?programming language(s) used and the available tools, such as?debuggers. Debuggers are software tools which enable the?programmer?to monitor the?execution?of a program, stop it, restart it, set?breakpoints, and change values in memory. The term?debugger?can also refer to the person who is doing the debugging.

Generally,?high-level programming languages, such as?Java, make debugging easier, because they have features such as?exception handling?and?type checking?that make real sources of erratic behaviour easier to spot. In programming languages such as?C?or?assembly, bugs may cause silent problems such as?memory corruption, and it is often difficult to see where the initial problem happened. In those cases,?memory debugger?tools may be needed.

In certain situations, general purpose software tools that are language specific in nature can be very useful. These take the form of?static code analysis tools. These tools look for a very specific set of known problems, some common and some rare, within the source code, concentrating more on the semantics (e.g. data flow) rather than the syntax, as compilers and interpreters do.

Both commercial and free tools exist for various languages; some claim to be able to detect hundreds of different problems. These tools can be extremely useful when checking very large source trees, where it is impractical to do code walk-throughs. A typical example of a problem detected would be a variable dereference that occurs?before?the variable is assigned a value. As another example, some such tools perform strong type checking when the language does not require it. Thus, they are better at locating likely errors in code that is syntactically correct. But these tools have a reputation of false positives, where correct code is flagged as dubious. The old Unix?lint?program is an early example.

For debugging electronic hardware (e.g.,?computer hardware) as well as low-level software (e.g.,?BIOSes,?device drivers) and?firmware, instruments such as?oscilloscopes,?logic analyzers, or?in-circuit emulators?(ICEs) are often used, alone or in combination. An ICE may perform many of the typical software debugger's tasks on low-level?software?and?firmware.

Debugging process[edit]

The debugging process normally begins with identifying the steps to reproduce the problem. This can be a non-trivial task, particularly with?parallel processes?and some?Heisenbugs?for example. The specific?user environment?and usage history can also make it difficult to reproduce the problem.

After the bug is reproduced, the input of the program may need to be simplified to make it easier to debug. For example, a bug in a compiler can make it?crash?when parsing a 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. Simplification may be done manually using a?divide-and-conquer?approach, in which the programmer attempts to remove some parts of original test case then checks if the problem still occurs. When debugging in a?GUI, the programmer can try skipping some user interaction from the original problem description to check if the remaining actions are sufficient for causing the bug to occur.

After the test case is sufficiently simplified, a programmer can use a debugger tool to examine program states (values of variables, plus the?call stack) and track down the origin of the problem(s). Alternatively,?traci