Working collaboratively on complex software systems often leads to situations where a developer enhances or extends system functionality, thereby however, introducing bugs. At best the unintentional changes are caught immediately by regression tests. Often however, the bugs are detected days or weeks later by other developers noticing strange system behavior while working on different parts of the system. Then it is a highly time-consuming task to trace back this behavior change to code changes in the past. In this paper we propose a technique for identifying the recently introduced change that is responsible for the unexpected behavior. The key idea is to combine dynamic, static, and code change information on the system to reduce the possibly great amount of code modifications to those that may affect the system while running its faulty behavior. After having applied this massive automated filtering step, developers receive support in semi-automatically identifying the root cause change by means of a trace exploration frontend. Within multiple synchronized views, developers explore when, how and why modified code locations are executed. The technique is implemented within a prototypical analysis tool that copes with large (> MLOC) C/C++ software systems. We demonstrate the approach by means of industrial case studies.
['Johannes Bohnet', 'Stefan Voigt', 'Jürgen Döllner']
Projecting code changes onto execution traces to support localization of recently introduced bugs