Conference Paper

Golden implementation driven software debugging

DOI: 10.1145/1882291.1882319 Conference: Proceedings of the 18th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2010, Santa Fe, NM, USA, November 7-11, 2010
Source: DBLP


The presence of a functionally correct golden implementation has a significant advantage in the software development life cycle. Such a golden implementation is exploited for software development in several domains, including embedded software --- a low resource-consuming version of the golden implementation. The golden implementation gives the functionality that the program is supposed to implement, and is used as a guide during the software development process. In this paper, we investigate the possibility of using the golden implementation as a reference model in software debugging. We perform a substantial case study involving the Busybox embedded Linux utilities while treating the GNU Core Utilities as the golden or reference implementation. Our debugging method consists of dynamic slicing with respect to the observable error in both the implementations (the golden implementation as well as the buggy software). During dynamic slicing we also perform a step-by-step weakest precondition computation of the observable error with respect to the statements in the dynamic slice. The formulae computed as weakest pre-condition in the two implementations are then compared to accurately locate the root cause of a given observable error. Experimental results obtained from Busybox suggest that our method performs well in practice and is able to pinpoint all the bugs recently published in [8] that could be reproduced on Busybox version 1.4.2. The bug report produced by our approach is concise and pinpoints the program locations inside the Busybox source that contribute to the difference in behavior.

Download full-text


Available from: Abhik Roychoudhury, Oct 10, 2015
31 Reads
  • Source
    • "Execution comparison. Execution comparison is used in debugging [1] [3] [37] [50], concurrency failure understanding [47], vulnerability detection [24], and binary reuse [25]. Comparative causality [41] produces bug explanations by replacing program states on the fly. "
    ACM SIGPLAN Notices 05/2015; 50(4):325-338. DOI:10.1145/2775054.2694394 · 0.66 Impact Factor
  • Source
    • "As an objective of investigating the incorrect value of hardware type, we set out to find the root cause as to why the variable hw is set to a NULL value at the end of the program execution [1]. "
    [Show abstract] [Hide abstract]
    ABSTRACT: Debugging is an unavoidable and most crucial aspect of software development life cycle. Especially when it comes the turn of embedded one. Due to the requirements of low code size and less resource consumption, the embedded softwares need to be upgraded all the time involving obvious change of code during development phase. This leads the huge risk of intrusion of bugs into the code at production time. In this paper we propose an approach of debugging embedded program in pseudo format, incorporating invariant analysis. Our methodology works on top of Daikon, a popular invariant analyzer. We have experimented with a simplified code snippet [1], used during debugging a reported error in BusyBox which is a de-facto standard for Linux in embedded systems.
  • [Show abstract] [Hide abstract]
    ABSTRACT: Delta debugging has been proposed for failure-inducing changes identification. Despite promising results, there are two practical factors that thwart the application of delta debugging: large number of tests and misleading false positives. To address the issues, we present a combination of coverage analysis and delta debugging that automatically isolates failure-inducing changes. Evaluations on twelve real regressions in GNU software demonstrate both the speed gain and effectiveness improvements.
    Proceedings - International Conference on Software Engineering 01/2012; DOI:10.1109/ICSE.2012.6227229
Show more