Debug Concurrent Programs With Visualization
and Inference of Event Structure
Xiaoquan Wu
1,2,3
wuxiaoquan07@otcaix.iscas.ac.cn
Jun Wei
1,2
wj@otciaix.iscas.ac.cn
Xu Wang
4
xu.wang@cs.ox.ac.uk
1
Technology Center of Software Engineering
Institute of Software, Chinese Academy of Sciences, China
2
State Key Laboratory of Computer Science
Institute of Software, Chinese Academy of Sciences, China
3
Graduate University of Chinese Academy of Sciences, China
4
Department of Computer Science, Oxford University, UK
Abstract—Owing to the inherent non-determinism of
concurrent programs, traditional debugging techniques are not
sufficient, especially in the scene of postmortem debugging.
Exploring defects through static analysis can avoid the high
cost of failure reproduction. In this paper, we present a novel
debugging method for concurrency bugs. We make use of
information in bug reports and slicing techniques, construct an
event structure model from Java program to reveal the
program behaviors related to the suspicious variables and
methods identified from bug reports. Utilize the nature of
event structure, we extract a small but sufficient subset from
all possible execution traces and visualize them with a graph.
This method can effectively help to comprehend concurrent
system and assist in locating concurrency bugs. We have
implemented a tool called JESVisT (Java event structure
visualization Tool) to support this method based on
open-source projects Bandera and Indus.
Keywords-Debug, visualization, concurrent programs, event
structure
I. INTRODUCTION
Nowadays, concurrent software is prevalent to make the
best use of the multi-core hardware. Unfortunately,
developing software with concurrent structure is an
error-prone task. Defects in concurrent programs are hard to
detect and fix due to its inherent non-determinism.
Testing is a common practice to detect defects in
software before releasing. The major challenge of testing
concurrent programs is how to control the execution order of
operations in different threads, to cover every branch for
each input test case, so that bugs are possible to be triggered
[1-3]. Despite some progress has been made, there are still
many of unsolved problems.
Postmortem debugging is a technique of debugging a
program after it fails. This always happens in the phase of
software maintenance. The classic approach to debug
sequential programs involves repeatedly stopping the
program during execution, then examining whether the state
being as expected. However, this kind of debugging
technique is not appropriate for concurrent programs. The
main problems associate with debugging concurrent
programs are the “probe effect” and non-repeatability [4].
Probe effect is an unintended alteration in system behavior
caused by measuring that system. It means the attempt to
observe the behavior of concurrent programs will change
their behavior. Non-repeatability means lacking of a global
synchronized clock makes the failure hard to repeat. Besides,
even if being luckily observed, it is still difficult to infer the
root cause of a failure and then fix it correctly. Current study
has pointed out that many of concurrency bugs failed to be
fixed in the first attempt. Even worse, new bugs were
introduced in the repair process [5].
Techniques related to debugging concurrent programs
include runtime monitoring, capture / replay and
visualization. Nevertheless, they are far away from
perfectness, especially in the case of debugging from a bug
report. Runtime monitoring aims at identifying violations
exposed by a given execution trace. However, triggering a
concurrency bug by exploring just one interleaving is
unlikely [4]. The capture / replay technique aims at
deterministically replaying executions of concurrent
programs. The main issue is how to ensure that threads
scheduling during replay is exactly the same as that during
capture [6]. Sometimes the process of capture and replay are
separately done by different people. Moreover, bug reporter
can only capture and record part of execution information,
which makes replaying impossible [7]. Visualization of
program behavior can help developers comprehend the
program, and has been widely used to assist debugging [6,
8-12]. Current works usually visualize the interaction traces
among threads with Unified Modeling Language (UML) [8,
13], some of them used the visualized model to
automatically detect deadlocks [8]. The limitation of these
works lies in two aspects: (1) They are based on dynamic
monitoring of a system. The information used to debug all
comes from already happened traces, while the defects which
can only be triggered by seldom happened traces cannot be
2012 19th Asia-Pacific Software Engineering Conference
1530-1362/12 $26.00 © 2012 IEEE
DOI 10.1109/APSEC.2012.134
683