74 research outputs found
Using Taint Analysis and Reinforcement Learning (TARL) to Repair Autonomous Robot Software
It is important to be able to establish formal performance bounds for
autonomous systems. However, formal verification techniques require a model of
the environment in which the system operates; a challenge for autonomous
systems, especially those expected to operate over longer timescales. This
paper describes work in progress to automate the monitor and repair of
ROS-based autonomous robot software written for an a-priori partially known and
possibly incorrect environment model. A taint analysis method is used to
automatically extract the data-flow sequence from input topic to publish topic,
and instrument that code. A unique reinforcement learning approximation of MDP
utility is calculated, an empirical and non-invasive characterization of the
inherent objectives of the software designers. By comparing off-line (a-priori)
utility with on-line (deployed system) utility, we show, using a small but real
ROS example, that it's possible to monitor a performance criterion and relate
violations of the criterion to parts of the software. The software is then
patched using automated software repair techniques and evaluated against the
original off-line utility.Comment: IEEE Workshop on Assured IEEE Workshop on Assured Autonomous Systems,
May, 202
Debugging Memory Issues In Embedded Linux: A Case Study
Debugging denotes the process of detecting root causes of unexpected
observable behaviors in programs, such as a program crash, an unexpected output
value being produced or an assertion violation. Debugging of program errors is
a difficult task and often takes a significant amount of time in the software
development life cycle. In the context of embedded software, the probability of
bugs is quite high. Due to requirements of low code size and less resource
consumption, embedded softwares typically do away with a lot of sanity checks
during development time. This leads to high chance of errors being uncovered in
the production code at run time. In this paper we propose a methodology for
debugging errors in BusyBox, a de-facto standard for Linux in embedded systems.
Our methodology works on top of Valgrind, a popular memory error detector and
Daikon, an invariant analyzer. We have experimented with two published errors
in BusyBox and report our findings in this paper.Comment: In proceedings of IEEE TechSym 2011, 14-16 January, 2011, IIT
kharagpur, Indi
A Critical Review of "Automatic Patch Generation Learned from Human-Written Patches": Essay on the Problem Statement and the Evaluation of Automatic Software Repair
At ICSE'2013, there was the first session ever dedicated to automatic program
repair. In this session, Kim et al. presented PAR, a novel template-based
approach for fixing Java bugs. We strongly disagree with key points of this
paper. Our critical review has two goals. First, we aim at explaining why we
disagree with Kim and colleagues and why the reasons behind this disagreement
are important for research on automatic software repair in general. Second, we
aim at contributing to the field with a clarification of the essential ideas
behind automatic software repair. In particular we discuss the main evaluation
criteria of automatic software repair: understandability, correctness and
completeness. We show that depending on how one sets up the repair scenario,
the evaluation goals may be contradictory. Eventually, we discuss the nature of
fix acceptability and its relation to the notion of software correctness.Comment: ICSE 2014, India (2014
Tortoise: Interactive System Configuration Repair
System configuration languages provide powerful abstractions that simplify
managing large-scale, networked systems. Thousands of organizations now use
configuration languages, such as Puppet. However, specifications written in
configuration languages can have bugs and the shell remains the simplest way to
debug a misconfigured system. Unfortunately, it is unsafe to use the shell to
fix problems when a system configuration language is in use: a fix applied from
the shell may cause the system to drift from the state specified by the
configuration language. Thus, despite their advantages, configuration languages
force system administrators to give up the simplicity and familiarity of the
shell.
This paper presents a synthesis-based technique that allows administrators to
use configuration languages and the shell in harmony. Administrators can fix
errors using the shell and the technique automatically repairs the higher-level
specification written in the configuration language. The approach (1) produces
repairs that are consistent with the fix made using the shell; (2) produces
repairs that are maintainable by minimizing edits made to the original
specification; (3) ranks and presents multiple repairs when relevant; and (4)
supports all shells the administrator may wish to use. We implement our
technique for Puppet, a widely used system configuration language, and evaluate
it on a suite of benchmarks under 42 repair scenarios. The top-ranked repair is
selected by humans 76% of the time and the human-equivalent repair is ranked
1.31 on average.Comment: Published version in proceedings of IEEE/ACM International Conference
on Automated Software Engineering (ASE) 201
- …