Daily software changes present an inherent risk of introducing bugs. To understand such bugs, it is crucial to understand why specific changes introduced the bugs. This is difficult and time-consuming. We propose Divergence-Driven Debugging, an approach using a debugger for detecting execution divergences between two versions of the same program. Developers can explore both versions' execution in full and compare them based on the detected divergences. We evaluate our approach on a bug scenario and show that our debugger highlights the live state and behavior required to understand why the changes produce the bug and to identify its root cause.

Empirically analyzing debugging activity is notoriously difficult. In particular, aggregating data (obtained from either observation or event logging) to verify hypotheses on developers' behavior is known to be challenging. Overall, the difficulty of studying debugging activities contributes to the need for more empirical evidence on how practitioners use debuggers. We propose debugging activity blueprint as a visual tool to analyze and navigate through all the events recorded in a programming environment. Our blueprint is a polymetric view representing the interaction between debuggers and other programming tools. Our blueprint highlights the flow of a debugging activity across the tools an IDE offers. An exploratory use case over three participants and two debugging tasks indicates that our blueprint supports a fine-grained analysis of complex debugging scenarios.

Debugging object-oriented programs requires understanding how objects interact with each other and how their state evolves during execution. It is an arduous activity, as there are no methods to support finding objects to debug and explore their interactions. In this paper we present Scopeo, a novel object-centric approach to explore objects and their interactions in object-oriented programs. We evaluate the performance of Scopeo and conclude its applicability to real debugging scenarios. We then open a discussion on the interest of this approach for future research into debugging and program comprehension.

In this paper, we share our experience with using reflection as a systematic tool to build advanced debuggers. We illustrate the usage and combination of reflection techniques for the implementation of object-centric debugging. Object-centric debugging is a technique for object-oriented systems that scopes debugging operations to specific objects. The implementation of this technique is not straightforward, as there are, to the best of our knowledge, no description in the literature about how to build such debugger.

Efficiently debugging a program requires program comprehension. To acquire it, developers explore the program execution, a task often performed using interactive debuggers. Unfortunately, exploring a program execution through standard interactive debuggers is a tedious and costly task. In this paper, we propose Time-Traveling Queries (TTQs) to ease program exploration. TTQs is a mechanism that automatically explores program executions to collect execution data. This data is used to time-travel through execution states, facilitating the exploration of program executions. We built a set of key TTQs based on typical questions developers ask when trying to understand programs. We conducted a user study with 34 participants to evaluate the impact of our queries on program comprehension activities. Results show that, compared to traditional debugging tools, TTQs significantly improve developers' precision, while reducing required time and efforts when performing program comprehension tasks.

Debugging is one of the most important and time consuming activities in software maintenance, yet mainstream debuggers are not well-adapted to several debugging scenarios. This has led to the research of new techniques covering specific families of complex bugs. Notably, recent research proposes to empower developers with scripting DSLs, plugin-based and moldable debuggers. However, these solutions are tailored to specific use-cases, or too costly for one-time-use scenarios. In this paper we argue that exposing a debugging scripting interface in mainstream debuggers helps in solving many challenging debugging scenarios. For this purpose, we present Sindarin, a scripting API that eases the expression and automation of different strategies developers pursue during their debugging sessions. Sindarin provides a GDB-like API, augmented with AST-bytecode-source code mappings and object-centric capabilities. To demonstrate the versatility of Sindarin, we reproduce several advanced breakpoints and non-trivial debugging mechanisms from the literature.