Software-Defect Localisation by Mining Dataflow-Enabled Call Graphs

Eichinger, Frank; Krogmann, Klaus; Klug, Roland; Böhm, Klemens

doi:10.1007/978-3-642-15880-3_33

Cited by 14 publications

(17 citation statements)

References 24 publications

(78 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Arguably the most researched debugging technique is delta debugging, which can be used to systematically narrow down possible failure causes by comparing a successful and an erroneous program execution [14]. Other types of debugging technique include slicing [3], focusing on anomalies [3], mining dynamic call graphs [15], statistical debugging [16], spectra-based fault localization [5], angelic debugging [6], data structure repair [8], relative debugging [17], automatic breakpoint generation [18] and automatic program fixing using contracts [7]. Finally, several combinations of the techniques exist [19]- [23].…”

Section: A Related Workmentioning

confidence: 99%

How developers debug

Beller

Spruit

Zaidman

2017

Preprint

View full text Add to dashboard Cite

Debugging software is an inevitable chore, often difficult and more time-consuming than expected, giving it the nickname the " dirty little secret of computer science." Surprisingly, we have little knowledge on how software engineers debug software problems in the real world, whether they use dedicated debugging tools, and how knowledgeable they are about debugging. This study aims to shed light on these aspects by following a mixedmethods research approach. We conduct an online survey capturing how 176 developers reflect on debugging. We augment this subjective survey data with objective observations from how 458 developers use the debugger included in their Integrated Development Abstract-Debugging software is an inevitable chore, often difficult and more time-consuming than expected, giving it the nickname the "dirty little secret of computer science." Surprisingly, we have little knowledge on how software engineers debug software problems in the real world, whether they use dedicated debugging tools, and how knowledgeable they are about debugging. This study aims to shed light on these aspects by following a mixed-methods research approach. We conduct an online survey capturing how 176 developers reflect on debugging. We augment this subjective survey data with objective observations from how 458 developers use the debugger included in their Integrated Development Environments (IDEs) by instrumenting the popular ECLIPSE and INTELLIJ IDEs with our purpose-built plugin WATCHDOG 2.0. To better explain the insights and controversies obtained from the previous steps, we followed up by conducting interviews with debugging experts and regular debugging users. Our results indicate that the the IDE-provided debugger is not used as often as expected, since "printf debugging" remains a feasible choice for many programmers. Furthermore, both knowledge and use of advanced debugging features are low. Our results call to strengthen hands-on debugging experience in Computer Science curricula and can and have already influenced the design of modern IDE debuggers.

show abstract

Section: A Related Workmentioning

confidence: 99%

How developers debug

Beller

Spruit

Zaidman

2017

Preprint

View full text Add to dashboard Cite

show abstract

“…A number of call-graph-based techniques for defect localisation has been proposed [4,8,9,11,12,21]. Their intuition is to mine for patterns in the call graphs which are characteristic for failing executions.…”

Section: Foundationsmentioning

confidence: 99%

“…Level of granularity: The graphs used in most approaches [4,8,11,12,21] are method-level call graphs, i.e., nodes represent methods and edges method calls. (See Figure 1(a) for an example.)…”

Section: Foundationsmentioning

confidence: 99%

“…Degree of reduction: In unreduced call graphs, as directly obtained from tracing, a method typically occurs several times, at various positions within a graph (see Figure 1(a)). [4,9,12,21] build on call graphs where exactly one node represents a method (total reduction, see Figure 1(c)). [8,11] in turn allow for more than one node.…”

Section: Foundationsmentioning

confidence: 99%

“…A variety of techniques has been proposed that mine dynamic call graphs, e.g., [4,8,11,12,21]. In such graphs, nodes typically represent methods and edges method invocations.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Scalable Software-Defect Localisation by Hierarchical Mining of Dynamic Call Graphs

Eichinger¹,

Oßner²,

Böhm³

2011

Proceedings of the 2011 SIAM International Conference on Data Mining

Self Cite

View full text Add to dashboard Cite

The localisation of defects in computer programmes is essential in software engineering and is important in domain-specific data mining. Existing techniques which build on call-graph mining localise defects well, but do not scale for large software projects. This paper presents a hierarchical approach with good scalability characteristics.It makes use of novel call-graph representations, frequent subgraph mining and feature selection. It first analyses call graphs of a coarse granularity, before it zooms-in into more fine-grained graphs. We evaluate our approach with defects in the Mozilla Rhino project: In our setup, it narrows down the code a developer has to examine to about 6% only.

show abstract

Data mining for defects in multicore applications: an entropy‐based call‐graph technique

Eichinger¹,

Pankratius

Böhm

2012

Concurrency and Computation

Self Cite

View full text Add to dashboard Cite

SUMMARYMulticore computers are ubiquitous. Expert developers as well as developers with little experience in parallelism are now asked to create multithreaded software in order to exploit parallelism in mainstream shared-memory hardware. However, finding and fixing parallel programming errors is a complex and arduous task. Programmers thus rely on tools such as race detectors that typically focus on reporting errors due to incorrect usage of synchronization constructs or due to missing synchronization. This arsenal of debugging techniques, however, is incomplete. This article presents a new perspective and addresses a largely unexplored direction of defect localization where a wrong usage of non-parallel programming constructs might cause wrong parallel application behavior. In particular, we make a contribution by showing how to use data-mining techniques to locate defects in multithreaded shared-memory programs. Our technique analyzes execution anomalies in a condensed representation of the dynamic call graphs of a multithreaded object-oriented application and identifies methods that contain a defect. Compared to race detectors that concentrate on finding incorrect synchronization, our method is able to reveal a wider range of defects that affect the control flow of a parallel program. Results from controlled experiments show that our data-mining approach not only finds race conditions in different types of multicore applications, but also other errors that cause incorrect parallel program behavior. Data-mining techniques offer a fruitful new ground for parallel program debugging, and we also discuss long-term directions for this interesting field.

show abstract

Software-Defect Localisation by Mining Dataflow-Enabled Call Graphs

Cited by 14 publications

References 24 publications

How developers debug

How developers debug

Scalable Software-Defect Localisation by Hierarchical Mining of Dynamic Call Graphs

Data mining for defects in multicore applications: an entropy‐based call‐graph technique

Contact Info

Product

Resources

About