2,663 research outputs found
Idempotent I/O for safe time travel
Debuggers for logic programming languages have traditionally had a capability
most other debuggers did not: the ability to jump back to a previous state of
the program, effectively travelling back in time in the history of the
computation. This ``retry'' capability is very useful, allowing programmers to
examine in detail a part of the computation that they previously stepped over.
Unfortunately, it also creates a problem: while the debugger may be able to
restore the previous values of variables, it cannot restore the part of the
program's state that is affected by I/O operations. If the part of the
computation being jumped back over performs I/O, then the program will perform
these I/O operations twice, which will result in unwanted effects ranging from
the benign (e.g. output appearing twice) to the fatal (e.g. trying to close an
already closed file). We present a simple mechanism for ensuring that every I/O
action called for by the program is executed at most once, even if the
programmer asks the debugger to travel back in time from after the action to
before the action. The overhead of this mechanism is low enough and can be
controlled well enough to make it practical to use it to debug computations
that do significant amounts of I/O.Comment: In M. Ronsse, K. De Bosschere (eds), proceedings of the Fifth
International Workshop on Automated Debugging (AADEBUG 2003), September 2003,
Ghent. cs.SE/030902
Debugging Scandal: The Next Generation
In 1997, the general lack of debugging tools was termed "the debugging scandal". Today, as new languages are emerging to support software evolution, once more debugging support is lagging. The powerful abstractions offered by new languages are compiled away and transformed into complex synthetic structures. Current debugging tools only allow inspection in terms of this complex synthetic structure; they do not support observation of program executions in terms of the original development abstractions. In this position paper, we outline this problem and present two emerging lines of research that ease the burden for debugger implementers and enable developers to debug in terms of development abstractions. For both approaches we identify language-independent debugger components and those that must be implemented for every new language. One approach restores the abstractions by a tool external to the program. The other maintains the abstractions by using a dedicated execution environment, supporting the relevant abstractions. Both approaches have the potential of improving debugging support for new languages. We discuss the advantages and disadvantages of both approaches, outline a combination thereof and also discuss open challenges
Out-Of-Place debugging: a debugging architecture to reduce debugging interference
Context. Recent studies show that developers spend most of their programming
time testing, verifying and debugging software. As applications become more and
more complex, developers demand more advanced debugging support to ease the
software development process.
Inquiry. Since the 70's many debugging solutions were introduced. Amongst
them, online debuggers provide a good insight on the conditions that led to a
bug, allowing inspection and interaction with the variables of the program.
However, most of the online debugging solutions introduce \textit{debugging
interference} to the execution of the program, i.e. pauses, latency, and
evaluation of code containing side-effects.
Approach. This paper investigates a novel debugging technique called
\outofplace debugging. The goal is to minimize the debugging interference
characteristic of online debugging while allowing online remote capabilities.
An \outofplace debugger transfers the program execution and application state
from the debugged application to the debugger application, both running in
different processes.
Knowledge. On the one hand, \outofplace debugging allows developers to debug
applications remotely, overcoming the need of physical access to the machine
where the debugged application is running. On the other hand, debugging happens
locally on the remote machine avoiding latency. That makes it suitable to be
deployed on a distributed system and handle the debugging of several processes
running in parallel.
Grounding. We implemented a concrete out-of-place debugger for the Pharo
Smalltalk programming language. We show that our approach is practical by
performing several benchmarks, comparing our approach with a classic remote
online debugger. We show that our prototype debugger outperforms by a 1000
times a traditional remote debugger in several scenarios. Moreover, we show
that the presence of our debugger does not impact the overall performance of an
application.
Importance. This work combines remote debugging with the debugging experience
of a local online debugger. Out-of-place debugging is the first online
debugging technique that can minimize debugging interference while debugging a
remote application. Yet, it still keeps the benefits of online debugging ( e.g.
step-by-step execution). This makes the technique suitable for modern
applications which are increasingly parallel, distributed and reactive to
streams of data from various sources like sensors, UI, network, etc
A Concurrency-Agnostic Protocol for Multi-Paradigm Concurrent Debugging Tools
Today's complex software systems combine high-level concurrency models. Each
model is used to solve a specific set of problems. Unfortunately, debuggers
support only the low-level notions of threads and shared memory, forcing
developers to reason about these notions instead of the high-level concurrency
models they chose.
This paper proposes a concurrency-agnostic debugger protocol that decouples
the debugger from the concurrency models employed by the target application. As
a result, the underlying language runtime can define custom breakpoints,
stepping operations, and execution events for each concurrency model it
supports, and a debugger can expose them without having to be specifically
adapted.
We evaluated the generality of the protocol by applying it to SOMns, a
Newspeak implementation, which supports a diversity of concurrency models
including communicating sequential processes, communicating event loops,
threads and locks, fork/join parallelism, and software transactional memory. We
implemented 21 breakpoints and 20 stepping operations for these concurrency
models. For none of these, the debugger needed to be changed. Furthermore, we
visualize all concurrent interactions independently of a specific concurrency
model. To show that tooling for a specific concurrency model is possible, we
visualize actor turns and message sends separately.Comment: International Symposium on Dynamic Language
- …