Hypothesizer: A Hypothesis-Based Debugger to Find and Test Debugging Hypotheses
Abdulaziz Alaboudi, Thomas D. LaToza
Abstract
When software defects occur, developers begin the debugging process by formulating hypotheses to explain the cause. These hypotheses guide the investigation process, determining which evidence developers gather to accept or reject the hypothesis, such as parts of the code and program state developers examine. However, existing debugging techniques do not offer support in finding relevant hypotheses, leading to wasted time testing hypotheses and examining code that ultimately does not lead to a fix. To address this issue, we introduce a new type of debugging tool, the hypothesis-based debugger, and an implementation of this tool in Hypothesizer. Hypothesis-based debuggers support developers from the beginning of the debugging process by finding relevant hypotheses until the defect is fixed. To debug using Hypothesizer, developers first demonstrate the defect, generating a recording of the program behavior with code execution, user interface events, network communications, and user interface changes. Based on this information and the developer’s descriptions of the symptoms, Hypothesizer finds relevant hypotheses, analyzes the code to identify relevant evidence to test the hypothesis, and generates an investigation plan through a timeline view. This summarizes all evidence items related to the hypothesis, indicates whether the hypothesis is likely to be true by showing which evidence items were confirmed in the recording, and enables the developer to quickly check evidence in the recording by viewing code snippets for each evidence item. A randomized controlled experiment with 16 professional developers found that, compared to traditional debugging tools and techniques such as breakpoint debuggers and Stack Overflow, Hypothesizer dramatically improved the success rate of fixing defects by a factor of five and decreased the time to debug by a factor of three.
Ask about this paper
Ask your agent about it.
Lune has read the top-tier papers around this one, so every answer names the papers it rests on.
Your agent calls
Lunesearch_papers
Free to start. No credit card required.
Terminal
Install the CLIlune papers get 738304df-b14a-4430-a3d6-dd84452c5bf8Cited by top-tier papers4
- Taming System Complexity: Demystifying Software Engineering Agents in Diagnosing Linux Kernel FaultsZhenhao Zhou, Zhuochen Huang, Yike He, Chong Wang et al.ACL 2026 · 5 citations
- Understanding the Linux Kernel, VisuallyHanzhi Liu, Yanyan Jiang, Chang XuEuroSys 2025 · 2 citations
- Wire Your Way: Hardware-Contextualized Guidance and In-situ Tests for Personalized Circuit PrototypingPunn Lertjaturaphat, Jungwoo Rhee, Jaewon You, Andrea BianchiCHI 2026 · 1 citation
- Building Software by Rolling the Dice: A Qualitative Study of Vibe CodingYi-Hung Chou, Boyuan Jiang, Yi Wen Chen, Mingyue Weng et al.FSE 2026 · 1 citation
Related papers
- Empirically Evaluating the Impact of Object-Centric Breakpoints on the Debugging of Object-Oriented ProgramsValentin Bourcier, Pooja Rani, Maximilian Ignacio Willembrinck Santander, Alberto Bacchelli et al.FSE 2025
- NuzzleBug: Debugging Block-Based Programs in ScratchAdina Deiner, Gordon FraserICSE 2024 · 14 citations
- Evaluating the Impact of Experimental Assumptions in Automated Fault LocalizationEzekiel O. Soremekun, Lukas Kirschner, Marcel Böhme, Mike PapadakisICSE 2023 · 9 citations
- On Debugging the Performance of Configurable Software Systems: Developer Needs and Tailored Tool SupportMiguel Velez, Pooyan Jamshidi, Norbert Siegmund, Sven Apel et al.ICSE 2022 · 21 citations
- Automated Program Repair, What Is It Good For? Not Absolutely Nothing!Hadeel Eladawy, Claire Le Goues, Yuriy BrunICSE 2024 · 15 citations
