Do stack traces help developers fix bugs?

Abstract

Abstract-A widely shared belief in the software engineering community is that stack traces are much sought after by developers to support them in debugging. But limited empirical evidence is available to confirm the value of stack traces to developers. In this paper, we seek to provide such evidence by conducting an empirical study on the usage of stack traces by developers from the ECLIPSE project. Our results provide strong evidence to this effect and also throws light on some of the patterns in bug fixing using stack traces. We expect the findings of our study to further emphasize the importance of adding stack traces to bug reports and that in the future, software vendors will provide more support in their products to help general users make such information available when filing bug reports.

Locating bugs without looking back

“…Overall 46-86% of BRs can be located by just assigning a high score to file names in certain positions of the BR summary, confirming the studies cited in the introduction that found file names mentioned in a large percentage of BRs (Saha et al 2013;Schröter et al 2010). The file name occurrences in other places of the BR are also scored by comparing BR and file terms in function scoreWithFileTerms (see Algorithm 2), but irrelevant files that match several terms may accumulate a large score that pushes the affected classes down the ranking.…”

“…However, BRs may contain useful information like stack traces, code fragments, patches and recreation steps (Bettenburg et al 2008). A study done by Schröter et al (2010) explored the usefulness of stack trace (ST) information found in the BRs. They investigated 161,500 BRs in the Eclipse project bug repository and found that around 8% (12947/161500) BRs contained ST information.…”

“…They investigated 161,500 BRs in the Eclipse project bug repository and found that around 8% (12947/161500) BRs contained ST information. After manually linking 30% (3940/12947) of those closed BRs to their affected files, 60% (2321/3940) revealed that the file modified to solve the bug was one of the files listed in the ST. Schröter et al (2010) note that STs identified in the study contained up to 1024 file names and a median of 25 files. Out of 2321 BRs with a ST, in 40% the affected file was in the very first position of the ST and in 80% it was within the first 6 positions.…”

“…The ST boost score is calculated by evaluating the files listed in the stack trace as well as the files referenced via import statements, defined as the closely referred ones. The approach considers only the first 10 files listed in a ST to be relevant, which was first introduced by Schröter et al (2010). Additionally, BugLocator's SimiScore function is utilised to calculate the similarity of the BR to the previously closed bugs and give favour to the files affected by those similar reports.…”

A Survey on Mining Software Repositories

“…However, the data sources for MSR are not limited to them, neither are they exclusive to each other. Thus, other data sources such as program execution information [30], crash reports [133], [185], and test cases [134] can also be introduced for MSR research. Execution information enables to reflect abnormal behavior which had not been detected by the bug report and it is little influenced by the variation of natural language [30].…”