Information Technology Reference
In-Depth Information
5> EndFun = fun(FD) ->
file:close(FD)
end,
#Fun<erl_eval.6.13229925>
6> onviso:merge(1, BeginFun, WorkFun, EndFun).
{ok, 15}
It is important to note that these only demonstrate basic usage. It is, of course,
possible to build significantly more complex functions for evaluating the traces
collected.
Future Work.
Currently two components comprise Onviso: Trace Setup API,
used to run, stop and analyse traces and Trace Management API used to man-
age units called trace cases, which keep together trace options, merge options
andtracedata.Inordertoencourage their usage, we plan to include our APIs
into existing OTP applications, namely runtime-tools for Trace Setup API and
observer for Trace Management API. We will also develop necessary documen-
tation and tutorials.
For Exago, we plan to run further pilot projects, e.g. on systems devel-
oped using other technologies and targeting different domains. We will improve
documentation and also experiment with other ways to define the specification.
6 Analysing Concurrent Systems
Our work on support for concurrent system analysis has included a number of
themes. Part of this is working out how to shrink counter-examples resulting
from an error found in a system, and to support repeatable testing. Another
major theme is development of McErlang, a model-checker for Erlang.
6.1
Shrinking Trace Counter-Examples
The goal here is to investigate, and implement, methods to shrink trace counter-
examples (resulting from testing or model checking concurrent systems) to ease
the task of understanding the reason for a fault detected during testing. As such
trace counter-examples frequently grow very large, having such a reduction facil-
ity is highly desirable. Our work has resulted in the development of a new tool,
PULSE, which is now implemented as part of the commercial QuickCheck distri-
bution. PULSE has been used for finding race conditions in industrial software.
See [CPS
+
09] for more information.
To achieve property-based testing of concurrent software, several challenges
have to be overcome. We must be able to decide whether tests have passed, and
to run tests repeatably.
Our approach to automatically simplifying failing tests is based on running
many simpler variations on the first failing test found, culminating in a minimal
