Papers
Topics
Authors
Recent
Gemini 2.5 Flash
Gemini 2.5 Flash
139 tokens/sec
GPT-4o
47 tokens/sec
Gemini 2.5 Pro Pro
43 tokens/sec
o3 Pro
4 tokens/sec
GPT-4.1 Pro
47 tokens/sec
DeepSeek R1 via Azure Pro
28 tokens/sec
2000 character limit reached

The Impact Of Bug Localization Based on Crash Report Mining: A Developers' Perspective (2403.10753v1)

Published 16 Mar 2024 in cs.SE and cs.IR

Abstract: Developers often use crash reports to understand the root cause of bugs. However, locating the buggy source code snippet from such information is a challenging task, mainly when the log database contains many crash reports. To mitigate this issue, recent research has proposed and evaluated approaches for grouping crash report data and using stack trace information to locate bugs. The effectiveness of such approaches has been evaluated by mainly comparing the candidate buggy code snippets with the actual changed code in bug-fix commits -- which happens in the context of retrospective repository mining studies. Therefore, the existing literature still lacks discussing the use of such approaches in the daily life of a software company, which could explain the developers' perceptions on the use of these approaches. In this paper, we report our experience of using an approach for grouping crash reports and finding buggy code on a weekly basis for 18 months, within three development teams in a software company. We grouped over 750,000 crash reports, opened over 130 issues, and collected feedback from 18 developers and team leaders. Among other results, we observe that the amount of system logs related to a crash report group is not the only criteria developers use to choose a candidate bug to be analyzed. Instead, other factors were considered, such as the need to deliver customer-prioritized features and the difficulty of solving complex crash reports (e.g., architectural debts), to cite some. The approach investigated in this study correctly suggested the buggy file most of the time -- the approach's precision was around 80%. In this study, the developers also shared their perspectives on the usefulness of the suspicious files and methods extracted from crash reports to fix related bugs.

Definition Search Book Streamline Icon: https://streamlinehq.com
References (29)
  1. L. An and F. Khomh. 2015a. Challenges and Issues of Mining Crash Reports. In 2015 IEEE 1st International Workshop on Software Analytics (SWAN). 5–8. https://doi.org/10.1109/SWAN.2015.7070480
  2. Le An and Foutse Khomh. 2015b. Challenges and issues of mining crash reports. In 2015 IEEE 1st International Workshop on Software Analytics (SWAN). IEEE, 5–8.
  3. From symptom to cause: localizing errors in counterexample traces. In ACM SIGPLAN Notices, Vol. 38. ACM, 97–105.
  4. What makes a good bug report?. In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering. 308–318.
  5. Daniel Cukier. 2013. DevOps patterns to scale web applications using cloud services. In Proceedings of the 2013 companion publication for conference on Systems, programming, & applications: software for humanity - SPLASH ’13. ACM Press, New York, New York, USA, 143–152. https://doi.org/10.1145/2508075.2508432
  6. ReBucket: a method for clustering duplicate crash reports based on call stack similarity. In 2012 34th International Conference on Software Engineering (ICSE). IEEE, 1084–1093.
  7. Works for me! characterizing non-reproducible bug reports. In Proceedings of the 11th working conference on mining software repositories. 62–71.
  8. Does the fault reside in a stack trace? Assisting crash localization by predicting crashing fault residence. Journal of Systems and Software 148 (2019), 88–104.
  9. Legion: Massively composing rankers for improved bug localization at adobe. IEEE Transactions on Software Engineering 48, 8 (2021), 3010–3024.
  10. James A Jones and Mary Jean Harrold. 2005. Empirical evaluation of the tarantula automatic fault-localization technique. In Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering. ACM, 273–282.
  11. Visualization of test information to assist fault localization. In Proceedings of the 24th International Conference on Software Engineering. ICSE 2002. IEEE, 467–477.
  12. An entropy evaluation approach for triaging field crashes: A case study of mozilla firefox. In 2011 18th Working Conference on Reverse Engineering. IEEE, 261–270.
  13. Richard Kilgore and Craig Chase. 1997. Re-execution of distributed programs to detect bugs hidden by racing messages. In Proceedings of the Thirtieth Hawaii International Conference on System Sciences, Vol. 1. IEEE, 423–432.
  14. Which crashes should i fix first?: Predicting top crashes at an early stage to prioritize debugging efforts. IEEE Transactions on Software Engineering 37, 3 (2011), 430–447.
  15. Debugging in the (very) large: ten years of implementation and experience. Commun. ACM 54, 7 (2011), 111–116.
  16. Ken Kovash. 2010. Dramatic Stability Improvements in Firefox. https://blog.mozilla.org/metrics/2010/04/08/dramatic-stability-improvements-in-firefox/
  17. An empirical study of the effectiveness of IR-based bug localization for large-scale industrial projects. Empirical Software Engineering 27, 2 (2022), 47.
  18. Improving Bug Localization by Mining Crash Reports: An Industrial Study. In 2020 IEEE International Conference on Software Maintenance and Evolution (ICSME). 766–775. https://doi.org/10.1109/ICSME46990.2020.00086
  19. Software fault localization using N-gram analysis. In International Conference on Wireless Algorithms, Systems, and Applications. Springer, 548–559.
  20. Automated support for classifying software failure reports. In 25th International Conference on Software Engineering, 2003. Proceedings. IEEE, 465–475.
  21. Why are Some Bugs Non-Reproducible?:–An Empirical Investigation using Data Fusion–. In 2020 IEEE international conference on software maintenance and evolution (ICSME). IEEE, 605–616.
  22. Do stack traces help developers fix bugs?. In 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010). IEEE, 118–121.
  23. Do automatically generated unit tests find real faults? an empirical study of effectiveness and challenges (t). In 2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 201–211.
  24. Laura Thomson. 2012. Socorro: Mozilla’s Crash Reporting System. https://blog.mozilla.org/webdev/2010/05/19/socorro-mozilla-crash-reports/
  25. Improving bug localization using correlations in crash reports. In 2013 10th Working Conference on Mining Software Repositories (MSR). IEEE, 247–256. https://doi.org/10.1109/MSR.2013.6624036
  26. Improving bug management using correlations in crash reports. Empirical Software Engineering 21, 2 (apr 2016), 337–367. https://doi.org/10.1007/s10664-014-9333-9
  27. Boosting bug-report-oriented fault localization with segmentation and stack-trace analysis. In 2014 IEEE International Conference on Software Maintenance and Evolution. IEEE, 181–190.
  28. ChangeLocator: locate crash-inducing changes based on crash reports. Empirical Software Engineering 23, 5 (2018), 2866–2900.
  29. CrashLocator: locating crashing faults based on crash stacks. In Proceedings of the 2014 International Symposium on Software Testing and Analysis - ISSTA 2014. ACM Press, New York, New York, USA, 204–214. https://doi.org/10.1145/2610384.2610386

Summary

We haven't generated a summary for this paper yet.

Ai Sparkles Streamline Icon: https://streamlinehq.com Summarize Now
X Twitter Logo Streamline Icon: https://streamlinehq.com

Tweets