2,114 research outputs found
A Monitoring Language for Run Time and Post-Mortem Behavior Analysis and Visualization
UFO is a new implementation of FORMAN, a declarative monitoring language, in
which rules are compiled into execution monitors that run on a virtual machine
supported by the Alamo monitor architecture.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
Learning Tractable Probabilistic Models for Fault Localization
In recent years, several probabilistic techniques have been applied to
various debugging problems. However, most existing probabilistic debugging
systems use relatively simple statistical models, and fail to generalize across
multiple programs. In this work, we propose Tractable Fault Localization Models
(TFLMs) that can be learned from data, and probabilistically infer the location
of the bug. While most previous statistical debugging methods generalize over
many executions of a single program, TFLMs are trained on a corpus of
previously seen buggy programs, and learn to identify recurring patterns of
bugs. Widely-used fault localization techniques such as TARANTULA evaluate the
suspiciousness of each line in isolation; in contrast, a TFLM defines a joint
probability distribution over buggy indicator variables for each line. Joint
distributions with rich dependency structure are often computationally
intractable; TFLMs avoid this by exploiting recent developments in tractable
probabilistic models (specifically, Relational SPNs). Further, TFLMs can
incorporate additional sources of information, including coverage-based
features such as TARANTULA. We evaluate the fault localization performance of
TFLMs that include TARANTULA scores as features in the probabilistic model. Our
study shows that the learned TFLMs isolate bugs more effectively than previous
statistical methods or using TARANTULA directly.Comment: Fifth International Workshop on Statistical Relational AI (StaR-AI
2015
A Debugging Tool for Distributed Systems
This paper describes parts of the design of a debugger for a distributed real-time multimedia system. Emphasis lies on the distributed aspect of debugging, which means that attention is paid to the external behaviour of the processes. This type of debugging is useful to find communication or synchronization errors. However, experience shows that this is not enough: the debugger must also provide hooks for the user to use traditional sequential debuggers. This type of debugging focuses on the internal behaviour - or internal logic - of processes. For the sequential debugging part a normal debugger like GDB can be taken. Three key elements of the debugger are events, filters and recognizers. By definition events are the lowest level of system activity that may be observed by the event debugger. Filters are applied to remove events from the stream of events produced by the debuggee that are of no interest for the programmer. Recognizers are used to recognize behaviour -right or wrong- of the system. By combining events, different levels of abstraction are introduced, thus alleviating the task of the programme
Design and Implementation of a Tracer Driver: Easy and Efficient Dynamic Analyses of Constraint Logic Programs
Tracers provide users with useful information about program executions. In
this article, we propose a ``tracer driver''. From a single tracer, it provides
a powerful front-end enabling multiple dynamic analysis tools to be easily
implemented, while limiting the overhead of the trace generation. The relevant
execution events are specified by flexible event patterns and a large variety
of trace data can be given either systematically or ``on demand''. The proposed
tracer driver has been designed in the context of constraint logic programming;
experiments have been made within GNU-Prolog. Execution views provided by
existing tools have been easily emulated with a negligible overhead.
Experimental measures show that the flexibility and power of the described
architecture lead to good performance. The tracer driver overhead is inversely
proportional to the average time between two traced events. Whereas the
principles of the tracer driver are independent of the traced programming
language, it is best suited for high-level languages, such as constraint logic
programming, where each traced execution event encompasses numerous low-level
execution steps. Furthermore, constraint logic programming is especially hard
to debug. The current environments do not provide all the useful dynamic
analysis tools. They can significantly benefit from our tracer driver which
enables dynamic analyses to be integrated at a very low cost.Comment: To appear in Theory and Practice of Logic Programming (TPLP),
Cambridge University Press. 30 pages
- …