Logs in bug reports provide important debugging information for developers. During the debugging process, developers need to study the bug report and examine user-provided logs to understand the system executions that lead to the problem. Intuitively, user-provided logs illustrate the problems that users encounter and may help developers with the debugging process. However, some logs may be incomplete or inaccurate, which can cause difficulty for developers to diagnose the bug, and thus, delay the bug fixing process. In this paper, we conduct an empirical study on the challenges that developers may encounter when analyzing the user-provided logs and their benefits. In particular, we study both log snippets and exception stack traces in bug reports. We conduct our study on 10 large-scale open-source systems with a total of 1,561 bug reports with logs (BRWL) and 7,287 bug reports without logs (BRNL). Our findings show that: 1) BRWL takes longer time (median ranges from 3 to 91 days) to resolve compared to BRNL (median ranges from 1 to 25 days). We also find that reporters may not attach accurate or sufficient logs (i.e., developers often ask for additional logs in the Comments section of a bug report), which extends the bug resolution time. 2) Logs often provide a good indication of where a bug is located. Most bug reports (73%) have overlaps between the classes that generate the logs and their corresponding fixed classes. However, there is still a large number of bug reports where there is no overlap between the logged and fixed classes. 3) Our manual study finds that there is often missing system execution information in the logs. Many logs only show the point of failure (e.g., exception) and do not provide a direct hint on the actual root cause. In fact, through call graph analysis, we find that 28% of the studied bug reports have the fixed classes reachable from the logged classes, while they are not visible in the logs attached in bug reports. In addition, some logging statements are removed in the source code as the system evolves, which may cause further challenges in analyzing the logs. In short, our findings highlight possible future research directions to better help practitioners attach or analyze logs in bug reports.

中文翻译：

---

揭开在错误报告中分析用户报告日志的挑战和好处的神秘面纱

错误报告中的日志为开发人员提供了重要的调试信息。在调试过程中，开发人员需要研究错误报告并检查用户提供的日志，以了解导致问题的系统执行情况。直观地，用户提供的日志说明了用户遇到的问题，可以帮助开发人员进行调试过程。但是，有些日志可能不完整或不准确，这会导致开发人员难以诊断错误，从而延迟错误修复过程。在本文中，我们对开发人员在分析用户提供的日志及其好处时可能遇到的挑战进行了实证研究。特别是，我们研究了错误报告中的日志片段和异常堆栈跟踪。我们对 10 个大型开源系统进行了研究，总共有 1 个，561 个带日志的错误报告 (BRWL) 和 7,287 个不带日志的错误报告 (BRNL)。我们的研究结果表明：1) 与 BRNL（中位数范围为 1 到 25 天）相比，BRWL 需要更长的时间（中位数范围为 3 到 91 天）来解决。我们还发现报告者可能没有附上准确或足够的日志（即开发人员经常在错误报告的评论部分要求额外的日志），从而延长了错误解决时间。2) 日志通常可以很好地指示错误所在的位置。大多数错误报告 (73%) 在生成日志的类与其相应的固定类之间存在重叠。但是，仍然有大量错误报告，其中记录的类和固定的类之间没有重叠。3）我们的手工研究发现，日志中经常缺少系统执行信息。许多日志只显示故障点（例如，异常），并没有提供有关实际根本原因的直接提示。事实上，通过调用图分析，我们发现 28% 的研究错误报告具有可从记录的类中访问的固定类，而它们在错误报告所附的日志中是不可见的。此外，随着系统的发展，源代码中删除了一些日志语句，这可能会给分析日志带来进一步的挑战。简而言之，我们的发现突出了未来可能的研究方向，以更好地帮助从业者附加或分析错误报告中的日志。虽然它们在错误报告中附加的日志中不可见。此外，随着系统的发展，源代码中删除了一些日志语句，这可能会给分析日志带来进一步的挑战。简而言之，我们的发现突出了未来可能的研究方向，以更好地帮助从业者附加或分析错误报告中的日志。虽然它们在错误报告中附加的日志中不可见。此外，随着系统的发展，源代码中删除了一些日志语句，这可能会给分析日志带来进一步的挑战。简而言之，我们的发现突出了未来可能的研究方向，以更好地帮助从业者附加或分析错误报告中的日志。