Firebug Research

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
(Academic papers related to Firebug.)
(Fixed formatting and structure)
 
(20 intermediate revisions not shown)
Line 1: Line 1:
-
= Academic papers related to Firebug. =
+
== Academic papers related to Firebug. ==
* Please add to this bibliography.
* Please add to this bibliography.
-
* ''Please add mini-review comments in italics with your signature. --[[User:Johnjbarton|Johnjbarton]] 21:55, 30 October 2009 (UTC) ''
+
* ''Please add mini-review comments in italics with your signature. --[[User:Johnjbarton|Johnjbarton]] 21:55, 30 October 2009 (UTC)''
 +
* Usually you can get copies of these papers by looking them up on [http://scholar.google.com/schhp?hl=en Google Scholar]
 +
* The funky @entries below are BibTex entries.
 +
* Often you can get the BibTex entries by looking up the title in Google then going to the ACM or IEEE sites where the document abstract, title, and bibtex entries are available but not the paper.
-
Sorry for the lack of formatting, I'll come back and clean up as soon as I can.
+
=== Domain-Specific Language Debuggers ===
-
 
+
-
== Breakpoints ==
+
-
 
+
-
== Domain-Specific Language Debuggers ==
+
As a specialized debugger, Firebug resembles debuggers for
As a specialized debugger, Firebug resembles debuggers for
domain-specific languages\cite{Wu04DomainEclipse}. However, the
domain-specific languages\cite{Wu04DomainEclipse}. However, the
Line 30: Line 29:
Premkumar Devanbu University of California, Davis, CA
Premkumar Devanbu University of California, Davis, CA
 +
<source lang="bibtex">
 +
@INPROCEEDINGS{Wu05weavinga,
 +
  author = {Hui Wu and Jeff Gray and Suman Roychoudhury and Marjan Mernik},
 +
  title = {Weaving a Debugging Aspect into Domain-Specific Language Grammars},
 +
  booktitle = {In SAC ’05: Proceedings of the 2005 ACM symposium on Applied computing},
 +
  year = {2005},
 +
  pages = {1370--1374},
 +
  publisher = {ACM Press}
 +
}
 +
</source>
-
@INPROCEEDINGS{Wu05weavinga,
+
<source lang="bibtex">
-
    author = {Hui Wu and Jeff Gray and Suman Roychoudhury and Marjan Mernik},
+
@MISC{Wu04DomainEclipse,
-
    title = {Weaving a Debugging Aspect into Domain-Specific Language Grammars},
+
  title = {Debugging Domain-Specific Languages in Eclipse},
-
    booktitle = {In SAC ’05: Proceedings of the 2005 ACM symposium on Applied computing},
+
  author = {Hui Wu and Jeff Gray and Marjan Mernik}
-
    year = {2005},
+
}
-
    pages = {1370--1374},
+
</source>
-
    publisher = {ACM Press}
+
-
}
+
-
 
+
-
@MISC{Wu04DomainEclipse,
+
-
    title = {Debugging Domain-Specific Languages in Eclipse},
+
-
    author ={ Hui Wu and Jeff Gray   and       Marjan Mernik}
+
-
}
+
-
== User Experience and Studies ==
+
=== User Experience and Studies ===
-
=== Debugging and the Experience of Immediacy ===
+
==== Debugging and the Experience of Immediacy ====
Firebug provides good tools to master ``space'', both the 2D space of
Firebug provides good tools to master ``space'', both the 2D space of
the Web page and the interface to the network. Our breakpoints help
the Web page and the interface to the network. Our breakpoints help
Line 56: Line 58:
Ungar et al.\cite{Unger97Immediacy}.
Ungar et al.\cite{Unger97Immediacy}.
-
@MISC{Unger97Immediacy,
+
<source lang="bibtex">
-
title={ Debugging and the Experience of Immediacy },
+
@MISC{Unger97Immediacy,
-
author = {D Ungar and  H Lieberman and C Fry},
+
  title = {Debugging and the Experience of Immediacy},
-
journal={Communications of the ACM },
+
  author = {D Ungar and  H Lieberman and C Fry},
-
}
+
  journal = {Communications of the ACM},
 +
}
 +
</source>
-
=== Locating Features in Source Code ===
+
==== Locating Features in Source Code ====
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.4624
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.4624
-
@MISC{Eisenbarth03locatingfeatures,
 
-
    author = {Thomas Eisenbarth and Rainer Koschke and Daniel Simon},
 
-
    title = {Locating Features in Source Code},
 
-
    year = {2003}
 
-
}
 
-
=== Why are Human-Computer Interfaces Difficult to Design and Implement? ===
+
Understanding the implementation of a certain feature of a system requires to identify the computational units of the system that contribute to this feature. In many cases, the mapping of features to the source code is poorly documented. In this paper, we present a semi-automatic technique that reconstructs the mapping for features that are triggered by the user and exhibit an observable behavior. The mapping is in general not injective; that is, a computational unit may contribute to several features. Our technique allows to distinguish between general and specific computational units with respect to a given set of features. For a set of features, it also identifies jointly and distinctly required computational units.
 +
 
 +
<source lang="bibtex">
 +
@MISC{Eisenbarth03locatingfeatures,
 +
  author = {Thomas Eisenbarth and Rainer Koschke and Daniel Simon},
 +
  title = {Locating Features in Source Code},
 +
  year = {2003}
 +
}
 +
</source>
 +
 
 +
==== Why are Human-Computer Interfaces Difficult to Design and Implement? ====
  @TECHREPORT{Myers93whyare,
  @TECHREPORT{Myers93whyare,
     author = {Brad A. Myers},
     author = {Brad A. Myers},
Line 78: Line 87:
     year = {1993}
     year = {1993}
  }
  }
-
== User Studies ==
 
-
=== Architecture of a Source Code Exploration Tool: A Software Engineering Case Study ===
+
=== User Studies ===
-
@TECHREPORT{Lethbridge97architectureof,
+
==== Architecture of a Source Code Exploration Tool: A Software Engineering Case Study ====
-
    author = {Timothy C. Lethbridge and Nicolas Anquetil},
+
<source lang="bibtex">
-
    title = {Architecture of a Source Code Exploration Tool: A Software Engineering Case Study},
+
@TECHREPORT{Lethbridge97architectureof,
-
    institution = {},
+
  author = {Timothy C. Lethbridge and Nicolas Anquetil},
-
    year = {1997}
+
  title = {Architecture of a Source Code Exploration Tool: A Software Engineering Case Study},
-
}  
+
  institution = {},
 +
  year = {1997}
 +
}
 +
</source>
 +
 
We discuss the design of a software system that helps software engineers (SE's) to perform the task we call just in time comprehension (JITC) of large bodies of source code. We discuss the requirements for such a system and how they were gathered by studying SE's at work. We then analyze our requirements with respect to other tools available to SE's for the JITC task. Next, we walk through system design and the objectoriented analysis process for our system, discussing key design issues. Some issues, such as dealing with multi-part names and conditional compilation are unexpectedly complex. 1 Introduction The goal of our research is to develop tools to help software engineers (SE's) more effectively maintain software. By analyzing the work of SE's, we have come to the conclusion that they spend a considerable portion of their time exploring source code, using a process that we call justin time program comprehension. As a result of our analysis, we have developed a set of requirements..
We discuss the design of a software system that helps software engineers (SE's) to perform the task we call just in time comprehension (JITC) of large bodies of source code. We discuss the requirements for such a system and how they were gathered by studying SE's at work. We then analyze our requirements with respect to other tools available to SE's for the JITC task. Next, we walk through system design and the objectoriented analysis process for our system, discussing key design issues. Some issues, such as dealing with multi-part names and conditional compilation are unexpectedly complex. 1 Introduction The goal of our research is to develop tools to help software engineers (SE's) more effectively maintain software. By analyzing the work of SE's, we have come to the conclusion that they spend a considerable portion of their time exploring source code, using a process that we call justin time program comprehension. As a result of our analysis, we have developed a set of requirements..
 +
==== An Exploratory Study of How Developers Seek, Relate, and Collect ... ====
-
=== An Exploratory Study of How Developers Seek, Relate, and Collect ... ===
+
''Studies eclipse users debugging Java code.''--[[User:Johnjbarton|Johnjbarton]] 22:31, 30 October 2009 (UTC)
-
@ARTICLE{Ko06anexploratory,
+
-
    author = {Andrew J. Ko and Brad A. Myers and Senior Member and Michael J. Coblenz and Htet Htet Aung},
+
-
    title = {An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks},
+
-
    journal = {IEEE Transactions on Software Engineering},
+
-
    year = {2006},
+
-
    volume = {32},
+
-
    pages = {971--987}
+
-
}
+
-
=== An Examination of Software Engineering Work Practices ===
+
Abstract:
 +
Much of software developers' time is spent understanding unfamiliar code. To better understand how developers gain this understanding and how software development environments might be involved, a study was performed in which developers were given an unfamiliar program and asked to work on two debugging tasks and three enhancement tasks for 70 minutes. The study found that developers interleaved three activities. They began by searching for relevant code both manually and using search tools; however, they based their searches on limited and misrepresentative cues in the code, environment, and executing program, often leading to failed searches. When developers found relevant code, they followed its incoming and outgoing dependencies, often returning to it and navigating its other dependencies; while doing so, however, Eclipse's navigational tools caused significant overhead. Developers collected code and other information that they believed would be necessary to edit, duplicate, or otherwise refer to later by encoding it in the interactive state of Eclipse's package explorer, file tabs, and scroll bars. However, developers lost track of relevant code as these interfaces were used for other tasks, and developers were forced to find it again. These issues caused developers to spend, on average, 35 percent of their time performing the mechanics of navigation within and between source files. These observations suggest a new model of program understanding grounded in theories of information foraging and suggest ideas for tools that help developers seek, relate, and collect information in a more effective and explicit manner.
-
@MISC{Singer97anexamination,
+
<source lang="bibtex">
-
    author = {Janice Singer and Timothy Lethbridge and Norman Vinson and Nicolas Anquetil},
+
@ARTICLE{Ko06anexploratory,
-
    title = {An Examination of Software Engineering Work Practices},
+
  author = {Andrew J. Ko and Brad A. Myers and Senior Member and Michael J. Coblenz and Htet Htet Aung},
-
    year = {1997}
+
  title = {An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks},
-
}
+
  journal = {IEEE Transactions on Software Engineering},
 +
  year = {2006},
 +
  volume = {32},
 +
  pages = {971--987}
 +
}
 +
</source>
-
== Breakpoints integrated with graphics ==  
+
==== An Examination of Software Engineering Work Practices ====
-
=== ZStep 95: A Reversible, Animated Source Code Stepper ===
+
<source lang="bibtex">
-
@MISC{Lieberman_zstep95:,
+
@MISC{Singer97anexamination,
-
    author = {Henry Lieberman and Christopher Fry},
+
  author = {Janice Singer and Timothy Lethbridge and Norman Vinson and Nicolas Anquetil},
-
    title = {ZStep 95: A Reversible, Animated Source Code Stepper},
+
  title = {An Examination of Software Engineering Work Practices},
-
    year = {}
+
  year = {1997}
-
}
+
}
 +
</source>
 +
 
 +
==== The Myth of Usability Testing ====
 +
[http://www.alistapart.com/articles/the-myth-of-usability-testing/ The Myth of Usability Testing]
 +
by Robert Hoekman Jr.
 +
 
 +
"Contrary to claims that usability professionals operate scientifically to identify problems in an interface, usability evaluations are at best less than scientific."
 +
 
 +
Reviews results from [http://www.dialogdesign.dk/CUE_papers.htm Comparative Usability Evaluation]
-
=== Bridging the gulf between code and behavior in programming ===
+
=== Breakpoints integrated with graphics ===
 +
==== ZStep 95: A Reversible, Animated Source Code Stepper ====
 +
<source lang="bibtex">
 +
@MISC{Lieberman_zstep95:,
 +
  author = {Henry Lieberman and Christopher Fry},
 +
  title = {ZStep 95: A Reversible, Animated Source Code Stepper},
 +
  year = {}
 +
}
 +
</source>
 +
==== Bridging the gulf between code and behavior in programming ====
 +
<source lang="bibtex">
  @INPROCEEDINGS{Lieberman95bridgingthe,
  @INPROCEEDINGS{Lieberman95bridgingthe,
     author = {Henry Lieberman and Christopher Fry},
     author = {Henry Lieberman and Christopher Fry},
Line 127: Line 157:
     publisher = {ACM Press}
     publisher = {ACM Press}
  }
  }
 +
</source>
 +
See also [[Firebug Research#Firecrystal: Understanding interactive behaviors in dynamic web pages|FireCrystal]] for a graphically integrated tracing project.
 +
==== HotWire: a visual debugger for C++ ====
 +
We argue that visualization is essential in a modern debugger. Instead of inserting debug statements throughout the code, it should be possible to easily define visualizations while running the program under control of the debugger, resulting in what might be called "visual printf's". A visualization of a C++ program can provide exciting insights. Bugs that cannot be found that easily with non-visual techniques are now found, just by watching the visualizations. However, the mechanisms to define the visualizations should be easy to understand, easy to apply and cause only minimal overhead to the programmer (who is the end-user of the visual debugger). HotWire is not only equipped with a couple of standard visualizations, but also with a small declarative script language (using constraints) that can be used to define new custom visualizations. This paper addresses user interface aspects of debugging tools. Specifically, the user interface of HotWire, a debugger for C++ and SmallTalk on AIX and OS/2 is described.
 +
<source lang="bibtex">
 +
@inproceedings{1267981,
 +
  author = {Laffra, Chris and Malhotra, Ashok},
 +
  title = {HotWire: a visual debugger for C++},
 +
  booktitle = {CTEC'94: Proceedings of the 6th conference on USENIX Sixth C++ Technical Conference},
 +
  year = {1994},
 +
  pages = {7--7},
 +
  location = {Cambridge, MA},
 +
  publisher = {USENIX Association},
 +
  address = {Berkeley, CA, USA},
 +
}
 +
</source>
 +
=== Diff, Debugging with diffs ===
-
+
==== Guard: A Relative Debugger ====
-
== Diff, Debugging with diffs ==
+
<source lang="bibtex">
 +
@ARTICLE{Sosic97guard:a,
 +
  author = {Rok Sosic and David Abramson},
 +
  title = {Guard: A relative debugger},
 +
  journal = {Software Practice and Experience},
 +
  year = {1997},
 +
  volume = {27},
 +
  pages = {94--21}
 +
}
 +
</source>
-
=== Guard: A Relative Debugger ===
 
-
 
-
@ARTICLE{Sosic97guard:a,
 
-
    author = {Rok Sosic and David Abramson},
 
-
    title = {Guard: A relative debugger},
 
-
    journal = {Software Practice and Experience},
 
-
    year = {1997},
 
-
    volume = {27},
 
-
    pages = {94--21}
 
-
}
 
A signifcant amount of software development is evolutionary, involving the modification of already existing programs. To a large extent, the modified programs produce the same results as the original program. This similarity between the original program and the development program is utilized by relative debugging. Relative debugging is a new concept that enables the user to compare the execution of two programs by specifying the expected correspondences between their states. A relative debugger concurrently executes the programs, verifies the correspondences, and reports any differences found. We describe our novel debugger, called Guard, and its relative debugging capabilities. Guard is implemented by using our library of debugging routines, called Dynascope, which provides debugging primitives in heterogeneous networked environments. To demonstrate the capacity of Guard for debugging in heterogeneous environments, we describe an experiment in which the execution of two programs is compared across Internet. The programs are written in different programming languages and executing on different computing platform.
A signifcant amount of software development is evolutionary, involving the modification of already existing programs. To a large extent, the modified programs produce the same results as the original program. This similarity between the original program and the development program is utilized by relative debugging. Relative debugging is a new concept that enables the user to compare the execution of two programs by specifying the expected correspondences between their states. A relative debugger concurrently executes the programs, verifies the correspondences, and reports any differences found. We describe our novel debugger, called Guard, and its relative debugging capabilities. Guard is implemented by using our library of debugging routines, called Dynascope, which provides debugging primitives in heterogeneous networked environments. To demonstrate the capacity of Guard for debugging in heterogeneous environments, we describe an experiment in which the execution of two programs is compared across Internet. The programs are written in different programming languages and executing on different computing platform.
 +
==== Isolating Cause-Effect Chains from Computer Programs ====
 +
<source lang="bibtex">
 +
@MISC{Zeller02isolatingcause-effect,
 +
  author = {Andreas Zeller},
 +
  title = {Isolating Cause-Effect Chains from Computer Programs},
 +
  year = {2002}
 +
}
 +
</source>
-
=== Isolating Cause-Effect Chains from Computer Programs ===
 
-
@MISC{Zeller02isolatingcause-effect,
 
-
    author = {Andreas Zeller},
 
-
    title = {Isolating Cause-Effect Chains from Computer Programs},
 
-
    year = {2002}
 
-
}
 
Consider the execution of a failing program as a sequence of program states. Each state induces the following state, up to the failure. Which variables and values of a program state are relevant for the failure? We show how the Delta Debugging algorithm isolates the relevant variables and values by systematically narrowing the state difference between a passing run and a failing run---by assessing the outcome of altered executions to determine wether a change in the program state makes a difference in the test outcome. Applying Delta Debugging to multiple states of the program automatically reveals the cause-effect chain of the failure---that is, the variables and values that caused the failure.
Consider the execution of a failing program as a sequence of program states. Each state induces the following state, up to the failure. Which variables and values of a program state are relevant for the failure? We show how the Delta Debugging algorithm isolates the relevant variables and values by systematically narrowing the state difference between a passing run and a failing run---by assessing the outcome of altered executions to determine wether a change in the program state makes a difference in the test outcome. Applying Delta Debugging to multiple states of the program automatically reveals the cause-effect chain of the failure---that is, the variables and values that caused the failure.
-
=== Debugging with Dynamic Slicing and Backtracking ===
+
==== Debugging with Dynamic Slicing and Backtracking ====
-
 
+
<source lang="bibtex">
-
@ARTICLE{Agrawal93debuggingwith,
+
@ARTICLE{Agrawal93debuggingwith,
-
    author = {Hiralal Agrawal and Richard A. Demillo and Eugene H. Spafford},
+
  author = {Hiralal Agrawal and Richard A. Demillo and Eugene H. Spafford},
-
    title = {Debugging with Dynamic Slicing and Backtracking},
+
  title = {Debugging with Dynamic Slicing and Backtracking},
-
    journal = {Software Practice and Experience},
+
  journal = {Software Practice and Experience},
-
    year = {1993},
+
  year = {1993},
-
    volume = {23},
+
  volume = {23},
-
    pages = {589--616}
+
  pages = {589--616}
-
}
+
}
 +
</source>
this paper we present a debugging model, based on dynamic program slicing and execution backtracking techniques, that easily lends itself to automation. This model is based on experience with using these techniques to debug software. We also present a prototype debugging tool, SPYDER, that explicitly supports the proposed model, and with which we are performing further debugging research
this paper we present a debugging model, based on dynamic program slicing and execution backtracking techniques, that easily lends itself to automation. This model is based on experience with using these techniques to debug software. We also present a prototype debugging tool, SPYDER, that explicitly supports the proposed model, and with which we are performing further debugging research
   
   
-
== Tracing-based Debugging ==
+
=== Tracing-based Debugging ===
-
@MISC{Fakultät_implementinga,
+
-
    author = {Der Philosophisch-naturwissenschaftlichen Fakultät and Der Universität Bern and Christoph Hofer and Leiter Der Arbeit and Prof Dr and Stéphane Ducasse and Dipl. -inform Marcus Denker},
+
-
    title = {Implementing a Backward-In-Time Debugger},
+
-
    year = {}
+
-
}
+
-
  @inproceedings{Lienhard08OOBack,
+
==== Omniscient Debugging ====
-
author = {Lienhard, Adrian and G\^{\i}rba, Tudor and Nierstrasz, Oscar},
+
 
-
title = {Practical Object-Oriented Back-in-Time Debugging},
+
http://www.lambdacs.com/debugger/
-
booktitle = {ECOOP '08: Proceedings of the 22nd European conference on Object-Oriented Programming},
+
 
-
year = {2008},
+
[http://www.ddj.com/development-tools/184406101 Dr. Dobb's article by Bil Lewis]
-
isbn = {978-3-540-70591-8},
+
 
-
pages = {592--615},
+
==== Back to the Future: Omniscient Debugging ====
-
location = {Paphos, Cypress},
+
Guillaume Pothier, Éric Tanter, "Back to the Future: Omniscient Debugging," IEEE Software, vol. 26, no. 6, pp. 78-85, November/December, 2009.
-
doi = {http://dx.doi.org/10.1007/978-3-540-70592-5_25},
+
-
publisher = {Springer-Verlag},
+
Debugging is a tedious and costly process that demands a profound understanding of the dynamic behavior of programs. An omniscient debugger makes the task of tracking down the root cause of bugs straightforward by enabling programmers to seamlessly navigate a buggy program's execution history. So why don't we all have an omniscient debugger in our favorite development environment? Are the challenges of making omniscient debugging practical a definitive barrier to its adoption? This article describes TOD, a scalable omniscient debugger for Java. TOD is integrated into the Eclipse IDE and paves the way for practical omniscient debugging.
-
address = {Berlin, Heidelberg},
+
   
-
}
+
<source lang="bibtex">
-
=== Practical Object-Oriented Back-in-Time Debugging ===
+
@article{ 10.1109/MS.2009.169,
-
http://scg.unibe.ch/archive/papers/Lien08bBackInTimeDebugging.pdf
+
  author = {Guillaume Pothier and Éric Tanter},
-
          Adrian Lienhard, Tudor Gˆrba and Oscar Nierstrasz
+
  title = {Back to the Future: Omniscient Debugging},
 +
  journal ={IEEE Software},
 +
  volume = {26},
 +
  number = {6},
 +
  issn = {0740-7459},
 +
  year = {2009},
 +
  pages = {78-85},
 +
  doi = {http://doi.ieeecomputersociety.org/10.1109/MS.2009.169},
 +
  publisher = {IEEE Computer Society},
 +
  address = {Los Alamitos, CA, USA},
 +
}
 +
</source>
 +
 
 +
==== Design and Implementation of a Backward-In-Time Debugger ====
 +
 
 +
Christoph Hofer, Marcus Denker, Stéphane Ducasse: Design and Implementation of a Backward-In-Time Debugger. NODe/GSEM 2006: 17-32
 +
 
 +
Traditional debugging and stepping execution trace are well-accepted techniques
 +
to understand deep internals about a program. However in many cases navigating
 +
the stack trace is not enough to find bugs, since the cause of a bug is often not in
 +
the stack trace anymore and old state is lost, so out of reach from the debugger. In
 +
this paper, we present the design and implementation of a backward-in-time debugger
 +
for a dynamic language, i.e., a debugger that allows one to navigate back the history
 +
of the application. We present the design and implementation of a backward-in-time
 +
debugger called UNSTUCK and show our solution to key implementation challenges
 +
 
 +
<source lang="bibtex">
 +
@MISC{Fakultät_implementinga,
 +
  author = {Die Philosophisch-naturwissenschaftlichen Fakultät an der Universität Bern and Christoph Hofer, Leiter der Arbeit and Prof. Dr. and Stéphane Ducasse and Dipl.-inform. Marcus Denker},
 +
  title = {Implementing a Backward-In-Time Debugger},
 +
  year = {}
 +
}
 +
</source>
 +
 
 +
==== Practical Object-Oriented Back-in-Time Debugging ====
 +
*http://scg.unibe.ch/archive/papers/Lien08bBackInTimeDebugging.pdf
 +
*Adrian Lienhard, Tudor Gˆrba and Oscar Nierstrasz
                                   ı
                                   ı
Abstract. Back-in-time debuggers are extremely useful tools for identifying the
Abstract. Back-in-time debuggers are extremely useful tools for identifying the
Line 207: Line 287:
performance penalty is significantly less than with other approaches.
performance penalty is significantly less than with other approaches.
-
=== A Dataflow Approach to Event-based Debugging ===
+
<source lang="bibtex">
 +
@inproceedings{Lienhard08OOBack,
 +
  author = {Lienhard, Adrian and G\^{\i}rba, Tudor and Nierstrasz, Oscar},
 +
  title = {Practical Object-Oriented Back-in-Time Debugging},
 +
  booktitle = {ECOOP '08: Proceedings of the 22nd European conference on Object-Oriented Programming},
 +
  year = {2008},
 +
  isbn = {978-3-540-70591-8},
 +
  pages = {592--615},
 +
  location = {Paphos, Cypress},
 +
  doi = {http://dx.doi.org/10.1007/978-3-540-70592-5_25},
 +
  publisher = {Springer-Verlag},
 +
  address = {Berlin, Heidelberg},
 +
}
 +
</source>
-
@ARTICLE{Olsson91adataflow,
+
--[[User:Johnjbarton|Johnjbarton]] 00:34, 13 March 2010 (UTC): Logging based debugging where the log contains object history and flows, filtered by object lifetime.
-
    author = {Ronald A. Olsson and Richard H. Crawford and W. Wilson Ho},
+
 
-
    title = {A Dataflow Approach to Event-based Debugging},
+
==== A Dataflow Approach to Event-based Debugging ====
-
    journal = {Software - Practice and Experience},
+
<source lang="bibtex">
-
    year = {1991},
+
@ARTICLE{Olsson91adataflow,
-
    volume = {21},
+
  author = {Ronald A. Olsson and Richard H. Crawford and W. Wilson Ho},
-
    pages = {209--229}
+
  title = {A Dataflow Approach to Event-based Debugging},
-
}
+
  journal = {Software - Practice and Experience},
 +
  year = {1991},
 +
  volume = {21},
 +
  pages = {209--229}
 +
}
 +
</source>
This paper describes a novel approach to event-based debugging. The approach is based on a (coarsegrained) dataflow view of events: a high-level event is recognized when an appropriate combination of lower-level events on which it depends has occurred. Event recognition is controlled using familiar programming language constructs. This approach is more flexible and powerful than current ones. It allows arbitrary debugger language commands to be executed when attempting to form higher-level events. It also allows users to specify event recognition in much the same way that they write programs. This paper also describes a prototype, Dalek, that employs the dataflow approach for debugging sequential programs. Dalek demonstrates the feasibility and attractiveness of the dataflow approach. One important motivation for this work is that current sequential debugging tools are inadequate. Dalek contributes toward remedying such inadequacies by providing events and a powerful debugging language
This paper describes a novel approach to event-based debugging. The approach is based on a (coarsegrained) dataflow view of events: a high-level event is recognized when an appropriate combination of lower-level events on which it depends has occurred. Event recognition is controlled using familiar programming language constructs. This approach is more flexible and powerful than current ones. It allows arbitrary debugger language commands to be executed when attempting to form higher-level events. It also allows users to specify event recognition in much the same way that they write programs. This paper also describes a prototype, Dalek, that employs the dataflow approach for debugging sequential programs. Dalek demonstrates the feasibility and attractiveness of the dataflow approach. One important motivation for this work is that current sequential debugging tools are inadequate. Dalek contributes toward remedying such inadequacies by providing events and a powerful debugging language
-
=== Configuration Debugging as Search: Finding the Needle in the Haystack ===
+
==== Debugging reinvented: asking and answering why and why not questions about program behavior. ====
-
@INPROCEEDINGS{Whitaker04configurationdebugging,
+
A. J. Ko and B. A. Myers. In ICSE '08: Proceedings of
-
    author = {Andrew Whitaker and Richard S. Cox and Steven D. Gribble},
+
the 30th international conference on Software
-
    title = {Configuration Debugging as Search: Finding the Needle in the Haystack},
+
engineering, pages 301{310, New York, NY, USA,
-
    booktitle = {In OSDI},
+
2008. ACM.
-
    year = {2004},
+
 
-
    pages = {77--90}
+
When software developers want to understand the reason for a
-
}
+
program’s behavior, they must translate their questions about the
 +
behavior into a series of questions about code, speculating about
 +
the causes in the process. The Whyline is a new kind of debugging
 +
tool that avoids such speculation by instead enabling developers
 +
to select a question about program output from a set of why did
 +
and why didn’t questions derived from the program’s code and
 +
execution. The tool then finds one or more possible explanations
 +
for the output in question, using a combination of static and
 +
dynamic slicing, precise call graphs, and new algorithms for
 +
determining potential sources of values and explanations for why
 +
a line of code was not reached. Evaluations of the tool on one task
 +
showed that novice programmers with the Whyline were twice as
 +
fast as expert programmers without it. The tool has the potential to
 +
simplify debugging in many software development contexts.
 +
 
 +
==== Firecrystal: Understanding interactive behaviors in dynamic web pages. ====
 +
S. Oney and B. Myers.  In IEEE
 +
Symposium on Visual Languages and Human-Centric
 +
Computing, 2009.
 +
 
 +
[http://www.stephenoney.com/firecrystal.php FireCrystal project page]
 +
 
 +
''This is one of the rare papers on Javascript debugging, by the group the create WhyLine (for Alice and Java). The demo is very cool, we want this in Firebug''--[[User:Johnjbarton|Johnjbarton]] 01:50, 12 November 2009 (UTC)
 +
 
 +
For developers debugging their own code, augmenting
 +
the code of others, or trying to learn the
 +
implementation details of interactive behaviors,
 +
understanding how web pages work is a fundamental
 +
problem. FireCrystal is a new Firefox extension that
 +
allows developers to indicate interactive behaviors of
 +
interest, and shows the specific code (Javascript, CSS,
 +
and HTML) that is responsible for those behaviors.
 +
FireCrystal provides an execution timeline that users
 +
can scrub back and forth, and the ability to select items
 +
of interest in the actual web page UI to see the
 +
associated code. FireCrystal may be especially useful
 +
for developers who are trying to learn the
 +
implementation details of interactive behaviors, so they
 +
can reuse these behaviors in their own web site.
 +
 
 +
==== Configuration Debugging as Search: Finding the Needle in the Haystack ====
 +
<source lang="bibtex">
 +
@INPROCEEDINGS{Whitaker04configurationdebugging,
 +
  author = {Andrew Whitaker and Richard S. Cox and Steven D. Gribble},
 +
  title = {Configuration Debugging as Search: Finding the Needle in the Haystack},
 +
  booktitle = {In OSDI},
 +
  year = {2004},
 +
  pages = {77--90}
 +
}
 +
</source>
 +
 
This work addresses the problem of diagnosing configuration errors that cause a system to function incorrectly. For example, a change to the local firewall policy could cause a network-based application to malfunction. Our approach is based on searching across time for the instant the system transitioned into a failed state. Based on this information, a troubleshooter or administrator can deduce the cause of failure by comparing system state before and after the failure. We present the Chronus tool, which automates the task of searching for a failure-inducing state change. Chronus takes as input a user-provided software probe, which differentiates between working and non-working states. Chronus performs “time travel ” by booting a virtual machine off the system’s disk state as it existed at some point in the past. By using binary search, Chronus can find the fault point with effort that grows logarithmically with log size. We demonstrate that Chronus can diagnose a range of common configuration errors for both client-side and server-side applications, and that the performance overhead of the tool is not prohibitive. 1
This work addresses the problem of diagnosing configuration errors that cause a system to function incorrectly. For example, a change to the local firewall policy could cause a network-based application to malfunction. Our approach is based on searching across time for the instant the system transitioned into a failed state. Based on this information, a troubleshooter or administrator can deduce the cause of failure by comparing system state before and after the failure. We present the Chronus tool, which automates the task of searching for a failure-inducing state change. Chronus takes as input a user-provided software probe, which differentiates between working and non-working states. Chronus performs “time travel ” by booting a virtual machine off the system’s disk state as it existed at some point in the past. By using binary search, Chronus can find the fault point with effort that grows logarithmically with log size. We demonstrate that Chronus can diagnose a range of common configuration errors for both client-side and server-side applications, and that the performance overhead of the tool is not prohibitive. 1
-
== Digital Signatures for User Assurances ==
+
=== Replay ===
 +
 
 +
==== Selective capture and replay of program executions ====
 +
 
 +
In this paper, we present a technique for selective capture and replay of program executions. Given an application, the technique allows for (1) selecting a subsystem of interest, (2) capturing at runtime all the interactions between such subsystem and the rest of the application, and (3) replaying the recorded interactions on the subsystem in isolation. The technique can be used in several scenarios. For example, it can be used to generate test cases from users' executions, by capturing and collecting partial executions in the field. For another example. it can be used to perform expensive dynamic analyses off-line. For yet another example, it can be used to extract subsystem or unit tests from system tests. Our technique is designed to be efficient, in that we only capture information that is relevant to the considered execution. To this end, we disregard all data that, although flowing through the boundary of the subsystem of interest, do not affect the execution. In the paper, we also present a preliminary evaluation of the technique performed using SCARPE, a prototype tool that implements our approach
 +
 
 +
<source lang="bibtex">
 +
@inproceedings{1083251,
 +
  author = {Orso, Alessandro and Kennedy, Bryan},
 +
  title = {Selective capture and replay of program executions},
 +
  booktitle = {WODA '05: Proceedings of the third international workshop on Dynamic analysis},
 +
  year = {2005},
 +
  isbn = {1-59593-126-0},
 +
  pages = {1--7},
 +
  location = {St. Louis, Missouri},
 +
  doi = {http://doi.acm.org/10.1145/1083246.1083251},
 +
  publisher = {ACM},
 +
  address = {New York, NY, USA},
 +
}
 +
</source>
 +
 
 +
==== Replaying and isolating failing multi-object interactions ====
 +
 
 +
When a program fails, there are typically multiple objects that contribute to the failure. Our JINSI tool automatically captures the failure-causing interaction between objects and isolates a sequence of calls that all are relevant for reproducing the failure. In contrast to existing work, JINSI also isolates relevant interaction within the observed component and thus across all layers of a complex application. In a proof of concept, JINSI has successfully isolated the interaction for a failure of the COLUMBA e-mail client, pinpointing the defect: "Out of the 187,532 interactions in the addressbook component, two incoming calls suffice to reproduce the failure."
 +
 
 +
<source lang="bibtex">
 +
@inproceedings{1401842,
 +
  author = {Burger, Martin and Zeller, Andreas},
 +
  title = {Replaying and isolating failing multi-object interactions},
 +
  booktitle = {WODA '08: Proceedings of the 2008 international workshop on dynamic analysis},
 +
  year = {2008},
 +
  isbn = {978-1-60558-054-8},
 +
  pages = {71--77},
 +
  location = {Seattle, Washington},
 +
  doi = {http://doi.acm.org/10.1145/1401827.1401842},
 +
  publisher = {ACM},
 +
  address = {New York, NY, USA},
 +
}
 +
</source>
 +
 
 +
=== Digital Signatures for User Assurances ===
Cryptographic Verification of Test Coverage Claims
Cryptographic Verification of Test Coverage Claims
Line 249: Line 437:
Publisher     
Publisher     
Elsevier North-Holland, Inc.  Amsterdam, The Netherlands, The Netherlands
Elsevier North-Holland, Inc.  Amsterdam, The Netherlands, The Netherlands
 +
 +
=== Unclassified ===
 +
 +
<source lang="bibtex">
 +
inproceedings(Abreu2008)
 +
  Abreu, R., Zoeteweij, P. & van Gemund, A.J.C.
 +
  An observation-based model for fault localization
 +
  WODA '08: Proceedings of the 2008 international workshop on dynamic analysis
 +
  ACM, 2008, pp. 64-70
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Arnold2008)
 +
  Arnold, M., Vechev, M. & Yahav, E.
 +
  QVM: an efficient runtime for detecting defects in deployed systems
 +
  OOPSLA '08: Proceedings of the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications
 +
  ACM, 2008, pp. 143-162
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Burger2008)
 +
  Burger, M. & Zeller, A.
 +
  Replaying and isolating failing multi-object interactions
 +
  WODA '08: Proceedings of the 2008 international workshop on dynamic analysis
 +
  ACM, 2008, pp. 71-77
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Chern2007)
 +
  Chern, R. & De Volder, K.
 +
  Debugging with control-flow breakpoints
 +
  AOSD '07: Proceedings of the 6th international conference on Aspect-oriented software development
 +
  ACM, 2007, pp. 96-106
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Chilimbi2009)
 +
  Chilimbi, T.M., Liblit, B., Mehra, K., Nori, A.V. & Vaswani, K.
 +
  HOLMES: Effective statistical debugging via efficient path profiling
 +
  ICSE '09: Proceedings of the 2009 IEEE 31st International Conference on Software Engineering
 +
  IEEE Computer Society, 2009, pp. 34-44
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(osdi2008-klee)
 +
  Cristian Cadar, D.D. & Dawson Engler, S.U.
 +
  KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs
 +
  OSDI 2008
 +
  2008
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Czyz2007)
 +
  Czyz, J.K. & Jayaraman, B.
 +
  Declarative and visual debugging in Eclipse
 +
  eclipse '07: Proceedings of the 2007 OOPSLA workshop on eclipse technology eXchange
 +
  ACM, 2007, pp. 31-35
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(DeBorger2009)
 +
  De Borger, W., Lagaisse, B. & Joosen, W.
 +
  A generic and reflective debugging architecture to support runtime visibility and traceability of aspects
 +
  AOSD '09: Proceedings of the 8th ACM international conference on Aspect-oriented software development
 +
  ACM, 2009, pp. 173-184
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Ko2008)
 +
  Ko, A.J. & Myers, B.A.
 +
  Debugging reinvented: asking and answering why and why not questions about program behavior
 +
  ICSE '08: Proceedings of the 30th international conference on Software engineering
 +
  ACM, 2008, pp. 301-310
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Lefebvre2009)
 +
  Lefebvre, G., Cully, B., Feeley, M.J., Hutchinson, N.C. & Warfield, A.
 +
  Tralfamadore: unifying source code and execution experience
 +
  EuroSys '09: Proceedings of the fourth ACM european conference on Computer systems
 +
  ACM, 2009, pp. 199-204
 +
</source>
 +
 +
<source lang="bibtex">
 +
article(Lencevicius2003)
 +
  Lencevicius, R., Hölzle, U. & Singh, A.K.
 +
  Dynamic Query-Based Debugging of Object-Oriented Programs
 +
  Automated Software Engg., Kluwer Academic Publishers, 2003, Vol. 10(1), pp. 39-74
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Lencevicius1997)
 +
  Lencevicius, R., Hölzle, U. & Singh, A.K.
 +
  Query-based debugging of object-oriented programs
 +
  OOPSLA '97: Proceedings of the 12th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
 +
  ACM, 1997, pp. 304-317
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Lewis2003)
 +
  Lewis, B. & Ducasse, M.
 +
  Using events to debug Java programs backwards in time
 +
  OOPSLA '03: Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
 +
  ACM, 2003, pp. 96-97
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(osdi2008-chess)
 +
  Madanlal Musuvathi, S.Q. & Thomas Ball, Microsoft Research; Gerard Basler, E.Z.P.A.N.U. o.W.M.I.N.U. o.C.R.
 +
  Finding and Reproducing Heisenbugs in Concurrent Programs
 +
  OSDI 2008
 +
  2008
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Navarro2008)
 +
  Navarro, L.D.B., Douence, R. & Südholt, M.
 +
  Debugging and testing middleware with aspect-based control-flow and causal patterns
 +
  Middleware '08: Proceedings of the 9th ACM/IFIP/USENIX International Conference on Middleware
 +
  Springer-Verlag New York, Inc., 2008, pp. 183-202
 +
</source>
 +
 +
<source lang="bibtex">
 +
article(Pothier2007)
 +
  Pothier, G., Tanter, & Piquer, J.
 +
  Scalable omniscient debugging
 +
  SIGPLAN Not., ACM, 2007, Vol. 42(10), pp. 535-552
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(osdi2008-chopstix)
 +
  Sapan Bhatia, Princeton University; Abhishek Kumar, G.I.M.E.F. & Larry Peterson, P.U.
 +
  Lightweight, High-Resolution Monitoring for Troubleshooting Production Systems
 +
  OSDI 2009
 +
  2008
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(1368110)
 +
  Xu, G. & Rountev, A.
 +
  Precise memory leak detection for java software using container profiling
 +
  ICSE '08: Proceedings of the 30th international conference on Software engineering
 +
  ACM, 2008, pp. 151-160
 +
</source>
 +
 +
<source lang="bibtex">
 +
book(Zeller2005)
 +
  Zeller, A.
 +
  Why Programs Fail: A Guide to Systematic Debugging
 +
  Morgan Kaufmann, 2005
 +
</source>
 +
 +
<source lang="bibtex">
 +
inproceedings(Zeller2002)
 +
  Zeller, A.
 +
  Isolating cause-effect chains from computer programs
 +
  SIGSOFT '02/FSE-10: Proceedings of the 10th ACM SIGSOFT symposium on Foundations of software engineering
 +
  ACM, 2002, pp. 1-10
 +
</source>
 +
 +
<source lang="bibtex">
 +
article(Zeller2002a)
 +
  Zeller, A. & Hildebrandt, R.
 +
  Simplifying and isolating failure-inducing input
 +
  #IEEE_J_SE#, 2002, Vol. 28(2), pp. 183-200
 +
</source>
 +
 +
== Other Lists of Debugging Papers ==
 +
* [http://www2.cs.uidaho.edu/~jeffery/aadebug.html Algorithmic and Automatic Debugging Home Page]
 +
* [http://xxx.lanl.gov/html/cs/0309027v4 AADEBUG 2003]

Latest revision as of 11:44, 12 April 2012

Contents

[edit] Academic papers related to Firebug.

  • Please add to this bibliography.
  • Please add mini-review comments in italics with your signature. --Johnjbarton 21:55, 30 October 2009 (UTC)
  • Usually you can get copies of these papers by looking them up on Google Scholar
  • The funky @entries below are BibTex entries.
  • Often you can get the BibTex entries by looking up the title in Google then going to the ACM or IEEE sites where the document abstract, title, and bibtex entries are available but not the paper.

[edit] Domain-Specific Language Debuggers

As a specialized debugger, Firebug resembles debuggers for domain-specific languages\cite{Wu04DomainEclipse}. However, the breakpoints we introduce here support higher-level graphical and network abstractions, not higher-level source-code abstractions. Firebug has domain specific breakpoints but when they hit, you are in general purpose source code. On the other hand, the extensive integration of Javascript and HTML/CSS in the Document Object Model combined with Firebug's integration of debugger views and the Web page blurs the line. We think it unlikely that debugger generation techniques\cite{Wu05weavinga} could produce a Firebug-like user experience.

Framework for debugging domain-specific languages Full text PdfPdf (126 KB) Source ACM SIGSOFT Software Engineering Notes archive Volume 25 , Issue 1 (January 2000) table of contents Page: 45 Year of Publication: 2000 ISSN:0163-5948 Author Premkumar Devanbu University of California, Davis, CA

@INPROCEEDINGS{Wu05weavinga,
  author = {Hui Wu and Jeff Gray and Suman Roychoudhury and Marjan Mernik},
  title = {Weaving a Debugging Aspect into Domain-Specific Language Grammars},
  booktitle = {In SAC ’05: Proceedings of the 2005 ACM symposium on Applied computing},
  year = {2005},
  pages = {1370--1374},
  publisher = {ACM Press}
}
@MISC{Wu04DomainEclipse,
  title = {Debugging Domain-Specific Languages in Eclipse},
  author = {Hui Wu and Jeff Gray and Marjan Mernik}
}

[edit] User Experience and Studies

[edit] Debugging and the Experience of Immediacy

Firebug provides good tools to master ``space, both the 2D space of the Web page and the interface to the network. Our breakpoints help connect these spatial dimensions to the source code that modifies them. But breakpoints are intrinsically ``at the wrong time: developers set them then run the program to hit them at a later time. This limits the kind of immediacy of debugging advocated by Ungar et al.\cite{Unger97Immediacy}.

@MISC{Unger97Immediacy,
  title = {Debugging and the Experience of Immediacy},
  author = {D Ungar and  H Lieberman and C Fry},
  journal = {Communications of the ACM},
}

[edit] Locating Features in Source Code

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.4624

Understanding the implementation of a certain feature of a system requires to identify the computational units of the system that contribute to this feature. In many cases, the mapping of features to the source code is poorly documented. In this paper, we present a semi-automatic technique that reconstructs the mapping for features that are triggered by the user and exhibit an observable behavior. The mapping is in general not injective; that is, a computational unit may contribute to several features. Our technique allows to distinguish between general and specific computational units with respect to a given set of features. For a set of features, it also identifies jointly and distinctly required computational units.

@MISC{Eisenbarth03locatingfeatures,
  author = {Thomas Eisenbarth and Rainer Koschke and Daniel Simon},
  title = {Locating Features in Source Code},
  year = {2003}
}

[edit] Why are Human-Computer Interfaces Difficult to Design and Implement?

@TECHREPORT{Myers93whyare,
   author = {Brad A. Myers},
   title = {Why are Human-Computer Interfaces Difficult to Design and Implement?},
   institution = {},
   year = {1993}
}

[edit] User Studies

[edit] Architecture of a Source Code Exploration Tool: A Software Engineering Case Study

@TECHREPORT{Lethbridge97architectureof,
  author = {Timothy C. Lethbridge and Nicolas Anquetil},
  title = {Architecture of a Source Code Exploration Tool: A Software Engineering Case Study},
  institution = {},
  year = {1997}
}

We discuss the design of a software system that helps software engineers (SE's) to perform the task we call just in time comprehension (JITC) of large bodies of source code. We discuss the requirements for such a system and how they were gathered by studying SE's at work. We then analyze our requirements with respect to other tools available to SE's for the JITC task. Next, we walk through system design and the objectoriented analysis process for our system, discussing key design issues. Some issues, such as dealing with multi-part names and conditional compilation are unexpectedly complex. 1 Introduction The goal of our research is to develop tools to help software engineers (SE's) more effectively maintain software. By analyzing the work of SE's, we have come to the conclusion that they spend a considerable portion of their time exploring source code, using a process that we call justin time program comprehension. As a result of our analysis, we have developed a set of requirements..

[edit] An Exploratory Study of How Developers Seek, Relate, and Collect ...

Studies eclipse users debugging Java code.--Johnjbarton 22:31, 30 October 2009 (UTC)

Abstract: Much of software developers' time is spent understanding unfamiliar code. To better understand how developers gain this understanding and how software development environments might be involved, a study was performed in which developers were given an unfamiliar program and asked to work on two debugging tasks and three enhancement tasks for 70 minutes. The study found that developers interleaved three activities. They began by searching for relevant code both manually and using search tools; however, they based their searches on limited and misrepresentative cues in the code, environment, and executing program, often leading to failed searches. When developers found relevant code, they followed its incoming and outgoing dependencies, often returning to it and navigating its other dependencies; while doing so, however, Eclipse's navigational tools caused significant overhead. Developers collected code and other information that they believed would be necessary to edit, duplicate, or otherwise refer to later by encoding it in the interactive state of Eclipse's package explorer, file tabs, and scroll bars. However, developers lost track of relevant code as these interfaces were used for other tasks, and developers were forced to find it again. These issues caused developers to spend, on average, 35 percent of their time performing the mechanics of navigation within and between source files. These observations suggest a new model of program understanding grounded in theories of information foraging and suggest ideas for tools that help developers seek, relate, and collect information in a more effective and explicit manner.

@ARTICLE{Ko06anexploratory,
  author = {Andrew J. Ko and Brad A. Myers and Senior Member and Michael J. Coblenz and Htet Htet Aung},
  title = {An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks},
  journal = {IEEE Transactions on Software Engineering},
  year = {2006},
  volume = {32},
  pages = {971--987}
}

[edit] An Examination of Software Engineering Work Practices

@MISC{Singer97anexamination,
  author = {Janice Singer and Timothy Lethbridge and Norman Vinson and Nicolas Anquetil},
  title = {An Examination of Software Engineering Work Practices},
  year = {1997}
}

[edit] The Myth of Usability Testing

The Myth of Usability Testing by Robert Hoekman Jr.

"Contrary to claims that usability professionals operate scientifically to identify problems in an interface, usability evaluations are at best less than scientific."

Reviews results from Comparative Usability Evaluation

[edit] Breakpoints integrated with graphics

[edit] ZStep 95: A Reversible, Animated Source Code Stepper

@MISC{Lieberman_zstep95:,
  author = {Henry Lieberman and Christopher Fry},
  title = {ZStep 95: A Reversible, Animated Source Code Stepper},
  year = {}
}

[edit] Bridging the gulf between code and behavior in programming

 @INPROCEEDINGS{Lieberman95bridgingthe,
    author = {Henry Lieberman and Christopher Fry},
    title = {Bridging the gulf between code and behavior in programming},
    booktitle = {CHI'95: Human Factors in Computing Systems},
    year = {1995},
    pages = {480--486},
    publisher = {ACM Press}
 }

See also FireCrystal for a graphically integrated tracing project.

[edit] HotWire: a visual debugger for C++

We argue that visualization is essential in a modern debugger. Instead of inserting debug statements throughout the code, it should be possible to easily define visualizations while running the program under control of the debugger, resulting in what might be called "visual printf's". A visualization of a C++ program can provide exciting insights. Bugs that cannot be found that easily with non-visual techniques are now found, just by watching the visualizations. However, the mechanisms to define the visualizations should be easy to understand, easy to apply and cause only minimal overhead to the programmer (who is the end-user of the visual debugger). HotWire is not only equipped with a couple of standard visualizations, but also with a small declarative script language (using constraints) that can be used to define new custom visualizations. This paper addresses user interface aspects of debugging tools. Specifically, the user interface of HotWire, a debugger for C++ and SmallTalk on AIX and OS/2 is described.

@inproceedings{1267981,
  author = {Laffra, Chris and Malhotra, Ashok},
  title = {HotWire: a visual debugger for C++},
  booktitle = {CTEC'94: Proceedings of the 6th conference on USENIX Sixth C++ Technical Conference},
  year = {1994},
  pages = {7--7},
  location = {Cambridge, MA},
  publisher = {USENIX Association},
  address = {Berkeley, CA, USA},
}

[edit] Diff, Debugging with diffs

[edit] Guard: A Relative Debugger

@ARTICLE{Sosic97guard:a,
  author = {Rok Sosic and David Abramson},
  title = {Guard: A relative debugger},
  journal = {Software Practice and Experience},
  year = {1997},
  volume = {27},
  pages = {94--21}
}

A signifcant amount of software development is evolutionary, involving the modification of already existing programs. To a large extent, the modified programs produce the same results as the original program. This similarity between the original program and the development program is utilized by relative debugging. Relative debugging is a new concept that enables the user to compare the execution of two programs by specifying the expected correspondences between their states. A relative debugger concurrently executes the programs, verifies the correspondences, and reports any differences found. We describe our novel debugger, called Guard, and its relative debugging capabilities. Guard is implemented by using our library of debugging routines, called Dynascope, which provides debugging primitives in heterogeneous networked environments. To demonstrate the capacity of Guard for debugging in heterogeneous environments, we describe an experiment in which the execution of two programs is compared across Internet. The programs are written in different programming languages and executing on different computing platform.

[edit] Isolating Cause-Effect Chains from Computer Programs

@MISC{Zeller02isolatingcause-effect,
  author = {Andreas Zeller},
  title = {Isolating Cause-Effect Chains from Computer Programs},
  year = {2002}
}

Consider the execution of a failing program as a sequence of program states. Each state induces the following state, up to the failure. Which variables and values of a program state are relevant for the failure? We show how the Delta Debugging algorithm isolates the relevant variables and values by systematically narrowing the state difference between a passing run and a failing run---by assessing the outcome of altered executions to determine wether a change in the program state makes a difference in the test outcome. Applying Delta Debugging to multiple states of the program automatically reveals the cause-effect chain of the failure---that is, the variables and values that caused the failure.

[edit] Debugging with Dynamic Slicing and Backtracking

@ARTICLE{Agrawal93debuggingwith,
  author = {Hiralal Agrawal and Richard A. Demillo and Eugene H. Spafford},
  title = {Debugging with Dynamic Slicing and Backtracking},
  journal = {Software Practice and Experience},
  year = {1993},
  volume = {23},
  pages = {589--616}
}

this paper we present a debugging model, based on dynamic program slicing and execution backtracking techniques, that easily lends itself to automation. This model is based on experience with using these techniques to debug software. We also present a prototype debugging tool, SPYDER, that explicitly supports the proposed model, and with which we are performing further debugging research

[edit] Tracing-based Debugging

[edit] Omniscient Debugging

http://www.lambdacs.com/debugger/

Dr. Dobb's article by Bil Lewis

[edit] Back to the Future: Omniscient Debugging

Guillaume Pothier, Éric Tanter, "Back to the Future: Omniscient Debugging," IEEE Software, vol. 26, no. 6, pp. 78-85, November/December, 2009.

Debugging is a tedious and costly process that demands a profound understanding of the dynamic behavior of programs. An omniscient debugger makes the task of tracking down the root cause of bugs straightforward by enabling programmers to seamlessly navigate a buggy program's execution history. So why don't we all have an omniscient debugger in our favorite development environment? Are the challenges of making omniscient debugging practical a definitive barrier to its adoption? This article describes TOD, a scalable omniscient debugger for Java. TOD is integrated into the Eclipse IDE and paves the way for practical omniscient debugging.

@article{ 10.1109/MS.2009.169,
  author = {Guillaume Pothier and Éric Tanter},
  title = {Back to the Future: Omniscient Debugging},
  journal ={IEEE Software},
  volume = {26},
  number = {6},
  issn = {0740-7459},
  year = {2009},
  pages = {78-85},
  doi = {http://doi.ieeecomputersociety.org/10.1109/MS.2009.169},
  publisher = {IEEE Computer Society},
  address = {Los Alamitos, CA, USA},
}

[edit] Design and Implementation of a Backward-In-Time Debugger

Christoph Hofer, Marcus Denker, Stéphane Ducasse: Design and Implementation of a Backward-In-Time Debugger. NODe/GSEM 2006: 17-32

Traditional debugging and stepping execution trace are well-accepted techniques to understand deep internals about a program. However in many cases navigating the stack trace is not enough to find bugs, since the cause of a bug is often not in the stack trace anymore and old state is lost, so out of reach from the debugger. In this paper, we present the design and implementation of a backward-in-time debugger for a dynamic language, i.e., a debugger that allows one to navigate back the history of the application. We present the design and implementation of a backward-in-time debugger called UNSTUCK and show our solution to key implementation challenges

@MISC{Fakultät_implementinga,
  author = {Die Philosophisch-naturwissenschaftlichen Fakultät an der Universität Bern and Christoph Hofer, Leiter der Arbeit and Prof. Dr. and Stéphane Ducasse and Dipl.-inform. Marcus Denker},
  title = {Implementing a Backward-In-Time Debugger},
  year = {}
}

[edit] Practical Object-Oriented Back-in-Time Debugging

                                 ı

Abstract. Back-in-time debuggers are extremely useful tools for identifying the causes of bugs. Unfortunately the “omniscient” approaches that try to remember all previous states are impractical because they consume too much space or they are far too slow. Several approaches rely on heuristics to limit these penalties, but they ultimately end up throwing out too much relevant information. In this paper we propose a practical approach that attempts to keep track of only the relevant data. In contrast to other approaches, we keep object history information together with the regular objects in the application memory. Although seemingly counter- intuitive, this approach has the effect that data not reachable from current appli- cation objects (and hence, no longer relevant) is garbage collected. We describe the technical details of our approach, and we present benchmarks that demon- strate that memory consumption stays within practical bounds. Furthermore, the performance penalty is significantly less than with other approaches.

@inproceedings{Lienhard08OOBack,
  author = {Lienhard, Adrian and G\^{\i}rba, Tudor and Nierstrasz, Oscar},
  title = {Practical Object-Oriented Back-in-Time Debugging},
  booktitle = {ECOOP '08: Proceedings of the 22nd European conference on Object-Oriented Programming},
  year = {2008},
  isbn = {978-3-540-70591-8},
  pages = {592--615},
  location = {Paphos, Cypress},
  doi = {http://dx.doi.org/10.1007/978-3-540-70592-5_25},
  publisher = {Springer-Verlag},
  address = {Berlin, Heidelberg},
}

--Johnjbarton 00:34, 13 March 2010 (UTC): Logging based debugging where the log contains object history and flows, filtered by object lifetime.

[edit] A Dataflow Approach to Event-based Debugging

@ARTICLE{Olsson91adataflow,
  author = {Ronald A. Olsson and Richard H. Crawford and W. Wilson Ho},
  title = {A Dataflow Approach to Event-based Debugging},
  journal = {Software - Practice and Experience},
  year = {1991},
  volume = {21},
  pages = {209--229}
}

This paper describes a novel approach to event-based debugging. The approach is based on a (coarsegrained) dataflow view of events: a high-level event is recognized when an appropriate combination of lower-level events on which it depends has occurred. Event recognition is controlled using familiar programming language constructs. This approach is more flexible and powerful than current ones. It allows arbitrary debugger language commands to be executed when attempting to form higher-level events. It also allows users to specify event recognition in much the same way that they write programs. This paper also describes a prototype, Dalek, that employs the dataflow approach for debugging sequential programs. Dalek demonstrates the feasibility and attractiveness of the dataflow approach. One important motivation for this work is that current sequential debugging tools are inadequate. Dalek contributes toward remedying such inadequacies by providing events and a powerful debugging language

[edit] Debugging reinvented: asking and answering why and why not questions about program behavior.

A. J. Ko and B. A. Myers. In ICSE '08: Proceedings of the 30th international conference on Software engineering, pages 301{310, New York, NY, USA, 2008. ACM.

When software developers want to understand the reason for a program’s behavior, they must translate their questions about the behavior into a series of questions about code, speculating about the causes in the process. The Whyline is a new kind of debugging tool that avoids such speculation by instead enabling developers to select a question about program output from a set of why did and why didn’t questions derived from the program’s code and execution. The tool then finds one or more possible explanations for the output in question, using a combination of static and dynamic slicing, precise call graphs, and new algorithms for determining potential sources of values and explanations for why a line of code was not reached. Evaluations of the tool on one task showed that novice programmers with the Whyline were twice as fast as expert programmers without it. The tool has the potential to simplify debugging in many software development contexts.

[edit] Firecrystal: Understanding interactive behaviors in dynamic web pages.

S. Oney and B. Myers. In IEEE Symposium on Visual Languages and Human-Centric Computing, 2009.

FireCrystal project page

This is one of the rare papers on Javascript debugging, by the group the create WhyLine (for Alice and Java). The demo is very cool, we want this in Firebug--Johnjbarton 01:50, 12 November 2009 (UTC)

For developers debugging their own code, augmenting the code of others, or trying to learn the implementation details of interactive behaviors, understanding how web pages work is a fundamental problem. FireCrystal is a new Firefox extension that allows developers to indicate interactive behaviors of interest, and shows the specific code (Javascript, CSS, and HTML) that is responsible for those behaviors. FireCrystal provides an execution timeline that users can scrub back and forth, and the ability to select items of interest in the actual web page UI to see the associated code. FireCrystal may be especially useful for developers who are trying to learn the implementation details of interactive behaviors, so they can reuse these behaviors in their own web site.

[edit] Configuration Debugging as Search: Finding the Needle in the Haystack

@INPROCEEDINGS{Whitaker04configurationdebugging,
  author = {Andrew Whitaker and Richard S. Cox and Steven D. Gribble},
  title = {Configuration Debugging as Search: Finding the Needle in the Haystack},
  booktitle = {In OSDI},
  year = {2004},
  pages = {77--90}
}

This work addresses the problem of diagnosing configuration errors that cause a system to function incorrectly. For example, a change to the local firewall policy could cause a network-based application to malfunction. Our approach is based on searching across time for the instant the system transitioned into a failed state. Based on this information, a troubleshooter or administrator can deduce the cause of failure by comparing system state before and after the failure. We present the Chronus tool, which automates the task of searching for a failure-inducing state change. Chronus takes as input a user-provided software probe, which differentiates between working and non-working states. Chronus performs “time travel ” by booting a virtual machine off the system’s disk state as it existed at some point in the past. By using binary search, Chronus can find the fault point with effort that grows logarithmically with log size. We demonstrate that Chronus can diagnose a range of common configuration errors for both client-side and server-side applications, and that the performance overhead of the tool is not prohibitive. 1

[edit] Replay

[edit] Selective capture and replay of program executions

In this paper, we present a technique for selective capture and replay of program executions. Given an application, the technique allows for (1) selecting a subsystem of interest, (2) capturing at runtime all the interactions between such subsystem and the rest of the application, and (3) replaying the recorded interactions on the subsystem in isolation. The technique can be used in several scenarios. For example, it can be used to generate test cases from users' executions, by capturing and collecting partial executions in the field. For another example. it can be used to perform expensive dynamic analyses off-line. For yet another example, it can be used to extract subsystem or unit tests from system tests. Our technique is designed to be efficient, in that we only capture information that is relevant to the considered execution. To this end, we disregard all data that, although flowing through the boundary of the subsystem of interest, do not affect the execution. In the paper, we also present a preliminary evaluation of the technique performed using SCARPE, a prototype tool that implements our approach

@inproceedings{1083251,
  author = {Orso, Alessandro and Kennedy, Bryan},
  title = {Selective capture and replay of program executions},
  booktitle = {WODA '05: Proceedings of the third international workshop on Dynamic analysis},
  year = {2005},
  isbn = {1-59593-126-0},
  pages = {1--7},
  location = {St. Louis, Missouri},
  doi = {http://doi.acm.org/10.1145/1083246.1083251},
  publisher = {ACM},
  address = {New York, NY, USA},
}

[edit] Replaying and isolating failing multi-object interactions

When a program fails, there are typically multiple objects that contribute to the failure. Our JINSI tool automatically captures the failure-causing interaction between objects and isolates a sequence of calls that all are relevant for reproducing the failure. In contrast to existing work, JINSI also isolates relevant interaction within the observed component and thus across all layers of a complex application. In a proof of concept, JINSI has successfully isolated the interaction for a failure of the COLUMBA e-mail client, pinpointing the defect: "Out of the 187,532 interactions in the addressbook component, two incoming calls suffice to reproduce the failure."

@inproceedings{1401842,
  author = {Burger, Martin and Zeller, Andreas},
  title = {Replaying and isolating failing multi-object interactions},
  booktitle = {WODA '08: Proceedings of the 2008 international workshop on dynamic analysis},
  year = {2008},
  isbn = {978-1-60558-054-8},
  pages = {71--77},
  location = {Seattle, Washington},
  doi = {http://doi.acm.org/10.1145/1401827.1401842},
  publisher = {ACM},
  address = {New York, NY, USA},
}

[edit] Digital Signatures for User Assurances

Cryptographic Verification of Test Coverage Claims Premkumar Thomas Devanbu, Stuart G. Stubblebine February 2000

IEEE Transactions on Software Engineering , Volume 26 Issue 2 Publisher: IEEE Press

Volume 72 , Issue 1-2 (June 2008) table of contents Pages 40-51 Year of Publication: 2008 ISSN:0167-6423 Authors Stoney Jackson Premkumar Devanbu Kwan-Liu Ma Publisher Elsevier North-Holland, Inc. Amsterdam, The Netherlands, The Netherlands

[edit] Unclassified

inproceedings(Abreu2008)
  Abreu, R., Zoeteweij, P. & van Gemund, A.J.C.
  An observation-based model for fault localization
  WODA '08: Proceedings of the 2008 international workshop on dynamic analysis
  ACM, 2008, pp. 64-70
inproceedings(Arnold2008)
  Arnold, M., Vechev, M. & Yahav, E.
  QVM: an efficient runtime for detecting defects in deployed systems
  OOPSLA '08: Proceedings of the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications
  ACM, 2008, pp. 143-162
inproceedings(Burger2008)
  Burger, M. & Zeller, A.
  Replaying and isolating failing multi-object interactions
  WODA '08: Proceedings of the 2008 international workshop on dynamic analysis
  ACM, 2008, pp. 71-77
inproceedings(Chern2007)
  Chern, R. & De Volder, K.
  Debugging with control-flow breakpoints
  AOSD '07: Proceedings of the 6th international conference on Aspect-oriented software development
  ACM, 2007, pp. 96-106
inproceedings(Chilimbi2009)
  Chilimbi, T.M., Liblit, B., Mehra, K., Nori, A.V. & Vaswani, K.
  HOLMES: Effective statistical debugging via efficient path profiling
  ICSE '09: Proceedings of the 2009 IEEE 31st International Conference on Software Engineering
  IEEE Computer Society, 2009, pp. 34-44
inproceedings(osdi2008-klee)
  Cristian Cadar, D.D. & Dawson Engler, S.U.
  KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs
  OSDI 2008
  2008
inproceedings(Czyz2007)
  Czyz, J.K. & Jayaraman, B.
  Declarative and visual debugging in Eclipse
  eclipse '07: Proceedings of the 2007 OOPSLA workshop on eclipse technology eXchange
  ACM, 2007, pp. 31-35
inproceedings(DeBorger2009)
  De Borger, W., Lagaisse, B. & Joosen, W.
  A generic and reflective debugging architecture to support runtime visibility and traceability of aspects
  AOSD '09: Proceedings of the 8th ACM international conference on Aspect-oriented software development
  ACM, 2009, pp. 173-184
inproceedings(Ko2008)
  Ko, A.J. & Myers, B.A.
  Debugging reinvented: asking and answering why and why not questions about program behavior
  ICSE '08: Proceedings of the 30th international conference on Software engineering
  ACM, 2008, pp. 301-310
inproceedings(Lefebvre2009)
  Lefebvre, G., Cully, B., Feeley, M.J., Hutchinson, N.C. & Warfield, A.
  Tralfamadore: unifying source code and execution experience
  EuroSys '09: Proceedings of the fourth ACM european conference on Computer systems
  ACM, 2009, pp. 199-204
article(Lencevicius2003)
  Lencevicius, R., Hölzle, U. & Singh, A.K.
  Dynamic Query-Based Debugging of Object-Oriented Programs
  Automated Software Engg., Kluwer Academic Publishers, 2003, Vol. 10(1), pp. 39-74
inproceedings(Lencevicius1997)
  Lencevicius, R., Hölzle, U. & Singh, A.K.
  Query-based debugging of object-oriented programs
  OOPSLA '97: Proceedings of the 12th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
  ACM, 1997, pp. 304-317
inproceedings(Lewis2003)
  Lewis, B. & Ducasse, M.
  Using events to debug Java programs backwards in time
  OOPSLA '03: Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
  ACM, 2003, pp. 96-97
inproceedings(osdi2008-chess)
  Madanlal Musuvathi, S.Q. & Thomas Ball, Microsoft Research; Gerard Basler, E.Z.P.A.N.U. o.W.M.I.N.U. o.C.R.
  Finding and Reproducing Heisenbugs in Concurrent Programs
  OSDI 2008
  2008
inproceedings(Navarro2008)
  Navarro, L.D.B., Douence, R. & Südholt, M.
  Debugging and testing middleware with aspect-based control-flow and causal patterns
  Middleware '08: Proceedings of the 9th ACM/IFIP/USENIX International Conference on Middleware
  Springer-Verlag New York, Inc., 2008, pp. 183-202
article(Pothier2007)
  Pothier, G., Tanter, & Piquer, J.
  Scalable omniscient debugging
  SIGPLAN Not., ACM, 2007, Vol. 42(10), pp. 535-552
inproceedings(osdi2008-chopstix)
  Sapan Bhatia, Princeton University; Abhishek Kumar, G.I.M.E.F. & Larry Peterson, P.U.
  Lightweight, High-Resolution Monitoring for Troubleshooting Production Systems
  OSDI 2009
  2008
inproceedings(1368110)
  Xu, G. & Rountev, A.
  Precise memory leak detection for java software using container profiling
  ICSE '08: Proceedings of the 30th international conference on Software engineering
  ACM, 2008, pp. 151-160
book(Zeller2005)
  Zeller, A.
  Why Programs Fail: A Guide to Systematic Debugging
  Morgan Kaufmann, 2005
inproceedings(Zeller2002)
  Zeller, A.
  Isolating cause-effect chains from computer programs
  SIGSOFT '02/FSE-10: Proceedings of the 10th ACM SIGSOFT symposium on Foundations of software engineering
  ACM, 2002, pp. 1-10
article(Zeller2002a)
  Zeller, A. & Hildebrandt, R.
  Simplifying and isolating failure-inducing input
  #IEEE_J_SE#, 2002, Vol. 28(2), pp. 183-200

[edit] Other Lists of Debugging Papers

Personal tools