Using Clone Detection to Identify Bugs in
Concurrent Software
Kevin Jalbert, Jeremy S. Bradbury
Software Quality Research Group
Faculty of Science (Computer Science)
University of Ontario Institute of Technology
Oshawa, Ontario, Canada
{kevin.jalbert, jeremy.bradbury}@uoit.ca
Abstract—In this paper we propose an active testing approach
that uses clone detection and rule evaluation as the foundation for
detecting bug patterns in concurrent software. If we can identify
a bug pattern as being present then we can localize our testing
effort to the exploration of interleavings relevant to the potential
bug. Furthermore, if the potential bug is indeed a real bug, then
targeting specific thread interleavings instead of examining all
possible executions can increase the probability of the bug being
detected sooner.
Keywords-active testing, bug patterns, clone detection, concur-
rency, fault localization, testing, static analysis
I. INTRODUCTION
Concurrency is increasingly utilized in software applications
in order to exploit the benefits of multi-core processors [1].
Concurrent software is traditionally viewed as being more
difficult to program and test when compared with sequential
software due to the existence of possible thread interleavings.
Furthermore, concurrency bugs are difficult to identify since
they often involve multiple code fragments that only exhibit
incorrect behaviour during some of the thread interleavings.
Various techniques exist to detect concurrency bugs. Model
checking is one technique that uses state exploration to search
all path executions and finds a path that produces the con-
currency bug [2]. Noise makers represent another technique
that cause subtle random delays during execution in hopes of
forcing unusual thread interleavings that may exhibit abnormal
behaviour [3], [4]. Two criteria that are often used to assess
concurrency bug detection techniques are effectiveness and
efficiency. Effectiveness represents the ability of a given tech-
nique to find bugs in a software system. Efficiency represents
the amount of effort and resources required to find these
bugs. Exhaustive state exploration and the use of noise makers
can usually be classified as having high effectiveness with
low efficiency. One possible improvement to these techniques
is to use pre-processing (e.g., static analysis) to reduce the
search space and increase efficiency while maintaining the
level of effectiveness. This approach is called active testing
and operates by first localizing the potential faults and then
specifically testing them [5].
We propose an approach to active testing that is based on
localizing the testing effort by identifying potential bugs using
clone detection. Our approach uses previously identified bug
patterns as input to find similar bug patterns in concurrent
software. The identification of cloned source fragments from
the clone detection process makes it possible to identify the
location of potential concurrency bugs. If these potential bugs
can be identified then it becomes possible to localize the
testing effort to a specific section of the source code. For
example, in the case of noise makers we can localize the
insertion of delays around the bug’s code fragment locations.
In general, the aim of our work is to increase the efficiency
of existing testing tools by providing potential locations of
concurrency bugs; the first phase of active testing.
In Section II we present background information on de-
tecting bugs using clone detection and existing concurrency
bug detection tools. The formal specification of concurrency
bug patterns and an example of a bug pattern specification
follows in Section III. Section IV outlines our approach for
the identification of potential bugs. Specifically, we overview
our tool’s architecture as well as the overall detection process.
Our proposed evaluation is described in Section V and finally
in Section VI we present our conclusions and future work.
II. BACKGROUND
A. Detecting Bugs using Clone Detection Tools
Clone detection is a technique that is capable of detecting
similar code fragments in source code. These clones are not
restricted to exact matches and thus source code normalization
is often used to generalize the input. Additionally, objects in
the source code can be abstracted to identifiers so that two code
fragments can match even though the objects within them are
different. By using these techniques it becomes possible to
detected the following clone types [6]:
∙ Type I - “Identical code fragments except for variations
in whitespace, layout and comments.”
∙ Type II - “Syntactically identical fragments except for
variations in identifiers, literals, types, whitespace, layout
and comments.”
∙ Type III - “Copied fragments with further modifications
such as changed, added or removed statements, in addi-
tion to variations in identifiers, literals, types, whitespace,
layout and comments.”