Experiences with building distributed debuggers

Meier, Michael S.; Miller, K.; Pazel, Donald P.; Rao, Josyula R.; Russell, James R.

doi:10.1145/238020.238043

Cited by 7 publications

(4 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…IntelliTrace [13] is similar in that it allows users to index into a program trace by selecting an event, such as a button click or an exception. In addition, some effort has been made to generate JavaScript stack traces that cross event boundaries [15], and more generally across client-server boundaries [12].…”

Section: Related Workmentioning

confidence: 99%

Addressing misconceptions about code with always-on programming visualizations

Lieber

Brandt

Miller

2014

Proceedings of the SIGCHI Conference on Human Factors in Computing Systems

View full text Add to dashboard Cite

We present Theseus, an IDE extension that visualizes runtime behavior within a JavaScript code editor. By displaying real-time information about how code actually behaves during execution, Theseus proactively addresses misconceptions by drawing attention to similarities and differences between the programmer's idea of what code does and what it actually does. To understand how programmers would respond to this kind of an always-on visualization, we ran a lab study with graduate students, and interviewed 9 professional programmers who were asked to use Theseus in their day-to-day work. We found that users quickly adopted strategies that are unique to always-on, real-time visualizations, and used the additional information to guide their navigation through their code.

show abstract

Section: Related Workmentioning

confidence: 99%

Addressing misconceptions about code with always-on programming visualizations

Lieber

Brandt

Miller

2014

Proceedings of the SIGCHI Conference on Human Factors in Computing Systems

View full text Add to dashboard Cite

show abstract

“…Essentially, each process is controlled by a sequential debugger, and coordination between them is carried out by a centralized console or GUI. Most-well known examples of these types of debuggers include research prototypes like p2d2 [7], Node Prism [9], Net-Dbx [10], and CDB [20], and commercial debuggers such as TotalView [8], IBM's Distributed Debugger [38], and Allinea DDT [39]. In this work, we also take a breakpointbased approach as its features provide a simple but fundamental debugging toolbox.…”

Section: Breakpoint-based Debuggersmentioning

confidence: 99%

Distributed debugging for mobile networks

Boix

Noguera

Meuter

2014

Journal of Systems and Software

View full text Add to dashboard Cite

Debuggers are an integral part, albeit often neglected, of the development of distributed applications. Ambient-oriented programming (AmOP) is a distributed paradigm for applications running on mobile ad hoc networks. In AmOP the complexity of programming in a distributed setting is married with the network fragility and open topology of mobile applications. To our knowledge, there is no debugging approach that tackles both these issues. In this paper we argue that a novel kind of distributed debugger that we term an ambient-oriented debugger, is required. We present REME-D (read as remedy), an online ambient-oriented debugger that integrates techniques from distributed debugging (event-based debugging, message breakpoints) and proposes facilities to deal with ad hoc, fragile networks -epidemic debugging, and support for frequent disconnections.

show abstract

“…Core to a wide range of distributed system challenges is examining the causal and concurrent relationships among events of an execution. Some examples of these challenges are deadlock detection [2], debugging [6,11,12], rollback and recovery [5,9], termination detection [8,20], mutual exclusion violation [1] and global predicate evaluation [3,7,13,18]. Techniques designed to meet these challenges is an ongoing area of research.…”

Section: Introductionmentioning

confidence: 99%

Communication Analysis of Distributed Programs

Simmons

Edwards

Kearns

2006

Scientific Programming

View full text Add to dashboard Cite

Capturing and examining the causal and concurrent relationships of a distributed system is essential to a wide range of distributed systems applications. Many approaches to gathering this information rely on trace files of executions. The information obtained through tracing is limited to those executions observed. We present a methodology that analyzes the source code of the distributed system. Our analysis considers each process's source code and produces a single comprehensive graph of the system's possible behaviors. The graph, termed the partial order graph (POG), uniquely represents each possible partial order of the system. Causal and concurrent relationships can be extracted relative either to a particular partial order, which is synonymous to a single execution, or to a collection of partial orders. The graph provides a means of reasoning about the system in terms of relationships that will definitely occur, may possible occur, and will never occur. Distributed assert statements provide a means to monitor distributed system executions. By constructing thePOGprior to system execution, the causality information provided by thePOGenables run-time evaluation of the assert statement without relying on traces or addition messages.

show abstract

Experiences with building distributed debuggers

Cited by 7 publications

References 2 publications

Addressing misconceptions about code with always-on programming visualizations

Addressing misconceptions about code with always-on programming visualizations

Distributed debugging for mobile networks

Communication Analysis of Distributed Programs

Contact Info

Product

Resources

About