Firebug Research

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
(Bridging the gulf between code and behavior in programming)
(Tracing-based Debugging)
Line 180: Line 180:
   
   
== Tracing-based Debugging ==
== Tracing-based Debugging ==
 +
 +
=== Omniscient Debugging ===
 +
 +
http://www.lambdacs.com/debugger/
 +
 +
=== Implementing a Backward-In-Time Debugger ===
 +
  @MISC{Fakultät_implementinga,
  @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},
     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},
Line 186: Line 193:
  }
  }
-
@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},
 
-
}
 
=== Practical Object-Oriented Back-in-Time Debugging ===
=== Practical Object-Oriented Back-in-Time Debugging ===
http://scg.unibe.ch/archive/papers/Lien08bBackInTimeDebugging.pdf
http://scg.unibe.ch/archive/papers/Lien08bBackInTimeDebugging.pdf
Line 215: Line 210:
strate that memory consumption stays within practical bounds. Furthermore, the
strate that memory consumption stays within practical bounds. Furthermore, the
performance penalty is significantly less than with other approaches.
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},
 +
}
=== A Dataflow Approach to Event-based Debugging ===
=== A Dataflow Approach to Event-based Debugging ===

Revision as of 22:01, 30 October 2009

Contents

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)

Sorry for the lack of formatting, I'll come back and clean up as soon as I can.

Breakpoints

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}
}

User Experience and Studies

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 },
}

Locating Features in Source Code

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?

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

User Studies

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..


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

@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

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

Breakpoints integrated with graphics

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 = {}
}

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}
}

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},
}

Diff, Debugging with diffs

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.


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.

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

Tracing-based Debugging

Omniscient Debugging

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

Implementing a Backward-In-Time Debugger

@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 = {}
}

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 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},
}

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

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

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

Personal tools