Information Processing Letters
Efficiently computing static single assignment form and the control dependence graph
ACM Transactions on Programming Languages and Systems (TOPLAS)
Yesterday, my program worked. Today, it does not. Why?
ESEC/FSE-7 Proceedings of the 7th European software engineering conference held jointly with the 7th ACM SIGSOFT international symposium on Foundations of software engineering
A fast algorithm for finding dominators in a flowgraph
ACM Transactions on Programming Languages and Systems (TOPLAS)
DSD-Crasher: a hybrid analysis tool for bug finding
Proceedings of the 2006 international symposium on Software testing and analysis
SYNERGY: a new algorithm for property checking
Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering
BitBlaze: A New Approach to Computer Security via Binary Analysis
ICISS '08 Proceedings of the 4th International Conference on Information Systems Security
Penumbra: automatically identifying failure-relevant inputs using dynamic tainting
Proceedings of the eighteenth international symposium on Software testing and analysis
Darwin: an approach for debugging evolving programs
Proceedings of the the 7th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering
Test-Suite Augmentation for Evolving Software
ASE '08 Proceedings of the 2008 23rd IEEE/ACM International Conference on Automated Software Engineering
A decision procedure for bit-vectors and arrays
CAV'07 Proceedings of the 19th international conference on Computer aided verification
KLEE: unassisted and automatic generation of high-coverage tests for complex systems programs
OSDI'08 Proceedings of the 8th USENIX conference on Operating systems design and implementation
Test generation to expose changes in evolving programs
Proceedings of the IEEE/ACM international conference on Automated software engineering
Improving failure-inducing changes identification using coverage analysis
Proceedings of the 34th International Conference on Software Engineering
Practical isolation of failure-inducing changes for debugging regression faults
Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering
Comparative causality: explaining the differences between executions
Proceedings of the 2013 International Conference on Software Engineering
RADAR: a tool for debugging regression problems in C/C++ software
Proceedings of the 2013 International Conference on Software Engineering
| Hi-index | 0.00 |
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.