CSC/ECE 517 Fall 2009/wiki1b 1 db: Difference between revisions
No edit summary |
No edit summary |
||
(12 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
A '''debugger''' is a computer program (or a software tool) used by software developers to test, find and fix bugs in other programs. The debugger allows the software developer to monitor the program (s)he is trying to debug, stop and restart it, set breakpoints and even change the values in memory. With the advances of debuggers, they are now part of most [http://en.wikipedia.org/wiki/Integrated_development_environment IDEs] (Integrated Development Environments) which makes it easier for the developer to set the state of the program in execution and monitor the code in memory. | |||
== History == | |||
( | |||
When computers first appeared, so did programs and the need to debug them. Although not a debugger tool, the first way to debug a program was by analyzing the [http://www.wikipedia.org/wiki/Core_dump core dump] of the program that crashed. This allowed the developer to work on the problem in a separate system while the main system could continue being used for its main purpose. Early [http://en.wikipedia.org/wiki/Operating_systems operating systems] were not setup not allow debuggers to monitor running processes and so core dumps were used to understand the state of the process long after it had disappeared. | |||
( | |||
== Early Debuggers == | |||
Several debuggers have been made available through out the years, each to debug a different programming language, to debug on a different operating system, or on a different hardware architectures. Below are some of the earlier debuggers: | |||
* core dump debugging - analyzing the recorded state of a program after it has crashed | |||
* [http://www.wikipedia.org/wiki/Memory_debugger memory debugger] - tool to find memory leaks and buffer overflow | |||
* [http://www.wikipedia.org/wiki/Debug_(command) DEBUG] - built-in DOS and Windows debugger originally developed in 1981 | |||
* [http://www.wikipedia.org/wiki/GNU_Debugger GDB] - Command Line debugger, standard debugger for GNU application written in 1986. Works with several programming languages | |||
* [http://en.wikipedia.org/wiki/Kernel_debugger KDB] - Linux Kernel debugger | |||
* [http://www.wikipedia.org/wiki/Dbx_(debugger) DBX] - Command Line source-level debugger | |||
* [http://www.wikipedia.org/wiki/Intel_Debugger IDB] - Intel debugger | |||
=== Control Flow Debugging: === | |||
Programming errors may be caused by incorrect control flow or data flow. Debuggers make use of conditional breakpoints and single stepping to allow the programmer to test the flow of the program. | |||
Other programming languages, such as [http://www.wikipedia.org/wiki/Eiffel_(programming_language) Eiffel], provide built-in support for debugging through the use of conditional assertions. This differs from conditional breakpoints in that it is checked only at specific program execution states such as before a method invocation or after a method exits. | |||
=== Data Observation Debugging: === | |||
Memory inspection and Data Structure Display provide a way for programmers to peek into memory during the execution of a program. The amount of information may be large, so some debuggers provide a way of filtering that information and displaying only a subsection of all memory state. | |||
Data breakpoints combines control flow debugging with data observation by breaking (or stopping) the running program when a particular event occurs to a change in a variable. | |||
== Advances in Debugging == | |||
Several academic papers have been written in advances of debuggers. | |||
=== Distributed Parallel Programs: === | |||
Instant Replay [1] - A solution to log relative order of significant events to easily reproduce execution behavior of parallel programs | |||
Interrupt Replay [2] - An extension of Instant Replay, replaying programs in the presence of interrupts | |||
=== Multi-threaded Debugger: === | |||
Low-Intrusion Thread-aware Debugger [3] - A solution for multi-threaded scripting language programs, such as Perl5, Python and Ruby, where the execution of a single thread is suspended for debugging | |||
=== Automated Debugger: === | |||
Coca: an automated debugger for C [4] - Automates debugging process based on a sequence of events using the language semantics instead of source lines. | |||
== Debugging in Development Environments == | |||
With the advances of Commercial, such as [http://www.activestate.com/komodo Komodo], and Open Source Development Environments, such as [http://www.eclipse.org Eclipse] and [http://www.netbeans.org Netbeans], the advances in debugging have been astonishing. Different plug-ins can be added to each IDE to allow debugging of other languages. | |||
* Single-stepping | |||
** Step over - steps over any function call treating it as a single line of code | |||
** Trace Into - steps into the function allowing the programmer to single step each line inside the function also | |||
* Break Points - allows the program to start and stop at a particular point, without having the user to single-step several lines of code before reaching the point of interest | |||
* Watches - programmers can also monitor a variable's value by setting a watch on it | |||
* Multiple views for debugging | |||
** Expression view - Displays all objects that have been inspected and their fields | |||
** Breakpoint view - Displays all available breakpoints and allows enabling/disabling and deleting them | |||
** Debug view - shows active threads and stacks | |||
* Multiple types of breakpoints | |||
** Line - program execution breaks when the particular line of the program is reached | |||
** Method - program execution breaks when a particular method is invoked. Can also set hit count so that, for example, will only break when the method is called the 2nd time. | |||
** Field - program execution breaks when a particular variable is accessed or modified | |||
** Java Exception - program execution breaks when a particular exception is raised | |||
== References == | |||
[1] Debugging Parallel Programs with Instant Replay, ''IEEE transactions on computers'' LeBlanc yr:1987 vol:36 iss:4 pg:471-482 | |||
[2]Interrupt Replay: a debugging method for parallel programs with interrupts, ''Microprocessors and microsystems'' Audenaert yr:1994 vol:18 iss:10 pg:601-612 | |||
[3]Low-intrusion debugger for Python and Ruby distributed multi-thread programs, ''Transactions of the Information Processing Society of Japan'' Sato, yr:2004, vol:45, iss:12, pg:2741-2751 | |||
[4]Coca: an automated debugger for C, ''Proceedings of the 1999 International Conference on Software Engineering (IEEE Cat. No.99CB37002)'' Ducasse yr:1999, pg:504-513 | |||
== Citations and External Links == | |||
A guide to DEBUG: http://mirror.href.com/thestarman/asm/debug/debug.htm | |||
GNU Bulletin: http://web.cecs.pdx.edu/~trent/gnu/bull/02/nb.html |
Latest revision as of 03:53, 29 September 2009
A debugger is a computer program (or a software tool) used by software developers to test, find and fix bugs in other programs. The debugger allows the software developer to monitor the program (s)he is trying to debug, stop and restart it, set breakpoints and even change the values in memory. With the advances of debuggers, they are now part of most IDEs (Integrated Development Environments) which makes it easier for the developer to set the state of the program in execution and monitor the code in memory.
History
When computers first appeared, so did programs and the need to debug them. Although not a debugger tool, the first way to debug a program was by analyzing the core dump of the program that crashed. This allowed the developer to work on the problem in a separate system while the main system could continue being used for its main purpose. Early operating systems were not setup not allow debuggers to monitor running processes and so core dumps were used to understand the state of the process long after it had disappeared.
Early Debuggers
Several debuggers have been made available through out the years, each to debug a different programming language, to debug on a different operating system, or on a different hardware architectures. Below are some of the earlier debuggers:
- core dump debugging - analyzing the recorded state of a program after it has crashed
- memory debugger - tool to find memory leaks and buffer overflow
- DEBUG - built-in DOS and Windows debugger originally developed in 1981
- GDB - Command Line debugger, standard debugger for GNU application written in 1986. Works with several programming languages
- KDB - Linux Kernel debugger
- DBX - Command Line source-level debugger
- IDB - Intel debugger
Control Flow Debugging:
Programming errors may be caused by incorrect control flow or data flow. Debuggers make use of conditional breakpoints and single stepping to allow the programmer to test the flow of the program.
Other programming languages, such as Eiffel, provide built-in support for debugging through the use of conditional assertions. This differs from conditional breakpoints in that it is checked only at specific program execution states such as before a method invocation or after a method exits.
Data Observation Debugging:
Memory inspection and Data Structure Display provide a way for programmers to peek into memory during the execution of a program. The amount of information may be large, so some debuggers provide a way of filtering that information and displaying only a subsection of all memory state.
Data breakpoints combines control flow debugging with data observation by breaking (or stopping) the running program when a particular event occurs to a change in a variable.
Advances in Debugging
Several academic papers have been written in advances of debuggers.
Distributed Parallel Programs:
Instant Replay [1] - A solution to log relative order of significant events to easily reproduce execution behavior of parallel programs
Interrupt Replay [2] - An extension of Instant Replay, replaying programs in the presence of interrupts
Multi-threaded Debugger:
Low-Intrusion Thread-aware Debugger [3] - A solution for multi-threaded scripting language programs, such as Perl5, Python and Ruby, where the execution of a single thread is suspended for debugging
Automated Debugger:
Coca: an automated debugger for C [4] - Automates debugging process based on a sequence of events using the language semantics instead of source lines.
Debugging in Development Environments
With the advances of Commercial, such as Komodo, and Open Source Development Environments, such as Eclipse and Netbeans, the advances in debugging have been astonishing. Different plug-ins can be added to each IDE to allow debugging of other languages.
- Single-stepping
- Step over - steps over any function call treating it as a single line of code
- Trace Into - steps into the function allowing the programmer to single step each line inside the function also
- Break Points - allows the program to start and stop at a particular point, without having the user to single-step several lines of code before reaching the point of interest
- Watches - programmers can also monitor a variable's value by setting a watch on it
- Multiple views for debugging
- Expression view - Displays all objects that have been inspected and their fields
- Breakpoint view - Displays all available breakpoints and allows enabling/disabling and deleting them
- Debug view - shows active threads and stacks
- Multiple types of breakpoints
- Line - program execution breaks when the particular line of the program is reached
- Method - program execution breaks when a particular method is invoked. Can also set hit count so that, for example, will only break when the method is called the 2nd time.
- Field - program execution breaks when a particular variable is accessed or modified
- Java Exception - program execution breaks when a particular exception is raised
References
[1] Debugging Parallel Programs with Instant Replay, IEEE transactions on computers LeBlanc yr:1987 vol:36 iss:4 pg:471-482
[2]Interrupt Replay: a debugging method for parallel programs with interrupts, Microprocessors and microsystems Audenaert yr:1994 vol:18 iss:10 pg:601-612
[3]Low-intrusion debugger for Python and Ruby distributed multi-thread programs, Transactions of the Information Processing Society of Japan Sato, yr:2004, vol:45, iss:12, pg:2741-2751
[4]Coca: an automated debugger for C, Proceedings of the 1999 International Conference on Software Engineering (IEEE Cat. No.99CB37002) Ducasse yr:1999, pg:504-513
Citations and External Links
A guide to DEBUG: http://mirror.href.com/thestarman/asm/debug/debug.htm
GNU Bulletin: http://web.cecs.pdx.edu/~trent/gnu/bull/02/nb.html