Non-functional bugs, e.g., performance bugs and security bugs, bear a heavy cost on both software developers and end-users. For example, IBM estimates the cost of a single data breach to be millions of dollars. Tools to reduce the occurrence, impact, and repair time of non-functional bugs can therefore provide key assistance for software developers racing to fix these issues. Identifying bug-inducing changes is a critical step in software quality assurance. In particular, the SZZ approach is commonly used to identify bug-inducing commits. However, the fixes to non-functional bugs may be scattered and separate from their bug-inducing locations in the source code. The nature of non-functional bugs may therefore make the SZZ approach a sub-optimal approach for identifying bug-inducing changes. Yet, prior studies that leverage or evaluate the SZZ approach do not consider non-functional bugs, leading to potential bias on the results. In this paper, we conduct an empirical study on the results of the SZZ approach when used to identify the inducing changes of the non-functional bugs in the NFBugs dataset. We eliminate a majority of the bug-inducing commits as they are not in the same method or class level. We manually examine whether each identified bug-inducing change is indeed the correct bug-inducing change. Our manual study shows that a large portion of non-functional bugs cannot be properly identified by the SZZ approach. By manually identifying the root causes of the falsely detected bug-inducing changes, we uncover root causes for false detection that have not been found by previous studies. We evaluate the identified bug-inducing changes based on three criteria from prior research, i.e., the earliest bug appearance, the future impact of changes, and the realism of bug introduction. We find that prior criteria may be irrelevant for non-functional bugs. Our results may be used to assist in future research on non-functional bugs, and highlight the need to complement SZZ to accommodate the unique characteristics of non-functional bugs.

非功能性错误（例如性能错误和安全性错误）给软件开发人员和最终用户带来沉重的成本。例如，IBM估计单个数据泄露的成本为数百万美元。因此，减少非功能性错误的发生，影响和修复时间的工具可以为软件开发人员争取解决这些问题的方法提供关键帮助。识别引起错误的更改是软件质量保证中的关键步骤。特别是，SZZ方法通常用于识别引起错误的提交。但是，对非功能性错误的修复可能分散且与源代码中引起错误的位置分开。因此，非功能性错误的性质可能会使SZZ方法成为识别导致错误的更改的次佳方法。然而，利用或评估SZZ方法的先前研究未考虑非功能性错误，从而导致结果可能存在偏差。在本文中，我们对SZZ方法的结果进行了实证研究，该方法用于确定NFBugs数据集中非功能性bug的诱发变化。我们消除了大多数导致错误的提交，因为它们不在同一方法或类级别。我们手动检查每个识别出的引起错误的更改是否确实是正确的引起错误的更改。我们的手动研究表明，SZZ方法无法正确识别出大部分非功能性错误。通过手动识别错误检测到的引起错误的更改的根本原因，我们发现了先前研究未发现的错误检测的根本原因。我们根据先前研究的三个标准评估已识别出的导致错误的更改，即最早的错误出现，更改的未来影响以及错误引入的真实性。我们发现，先前的标准可能与非功能性错误无关。我们的结果可用于协助将来对非功能性错误的研究，并强调需要补充SZZ以适应非功能性错误的独特特征。