# Locating Crashing Faults based on Crash Stack Traces

arXiv: https://arxiv.org/abs/1404.4100 · HTML: https://mlsanity.com/paper/1404.4100/

## Key facts

- Cited by 3 papers in the map (data through 14 Oct 2026).
- First posted on arXiv 15 Apr 2014.

## Built on by (most cited first, 3 of 3)

- [On the Role of Fault Localization Context for LLM-Based Program Repair](https://mlsanity.com/paper/2604.05481/) (2026)
- [Leveraging Large Language Models for Efficient Failure Analysis in Game Development](https://mlsanity.com/paper/2406.07084/) (2024)
- [Fault Localization via Fine-tuning Large Language Models with Mutation Generated Stack Traces](https://mlsanity.com/paper/2501.18005/) (2025)

## Abstract (arXiv)

Software crashes due to its increasing complexity. Once a crash happens, a crash report could be sent to software developers for investigation upon user permission. Because of the large number of crash reports and limited information, debugging for crashes is often a tedious and labor-intensive task. In this paper, we propose a statistical fault localization framework to help developers locate functions that contain crashing faults. We generate the execution traces for the failing traces based on the crash stack, and the passing traces from normal executions. We form program spectra by combining generated passing and failing trace, and then apply statistical fault localization techniques such as Ochiai to locate the crashing faults. We also propose two heuristics to improve the fault localization performance. We evaluate our approach using the real-world Firefox crash report data. The results show that the performance of our method is promising. Our approach permits developers to locate 63.9% crashing faults by examining only 5% Firefox 3.6 functions in the spectra.