Object-centric debugging aims at facilitating the debugging of object-oriented programs by focusing debugging operations on specific objects. This technique is tedious to use because developers have to manually find objects to debug, which is not straightforward. Time-traveling debuggers allows developers to explore executions back and forth in time. It has been shown that time-traveling features efectively facilitate debugging and program understanding. We propose to combine these techniques to benefit from both of them to debug objectoriented programs. Time-travel navigation could help finding and remembering objects by providing means to explore executions back and forth. Object-centric debugging could extend time-traveling debugging with object-centric exploration features. These techniques have never been combined, and the challenges and benefits of such combination have never been explored. We present SeekerOC, a time-traveling debugger prototype which provides object-centric debugging support. To combine both techniques, we use Time-Traveling Queries, a query system to automatically explore executions. We discuss the expected benefits of this combination, and we argue that exploring object-centric time-traveling debugging will open new research perspectives towards more efective debugging techniques and tools for object-oriented systems.
To debug their programs, developers use debuggers which traditionally provide a set of
standard debugging operations. Some of these debugging operations (e.g., breakpoints)
are defined for a class ( e.g., in a method) and apply to all instances of that class.
Meanwhile, object-centric debugging is a technique proposed to improve the debugging
of object-oriented systems by scoping object-centric debugging operations to specific
objects [
Time-traveling debugging to the rescue. With time-traveling debuggers, developers
are able to deterministically explore a program execution back and forth in time [
We argue that this capability of navigating through time could improve the application of object-centric debugging. Developers would be able to explore the execution to find which object to debug without the risk of missing an interesting moment, and to navigate directly to events of interest for those objects. Furthermore, time-traveling debuggers could provide new support for tracking objects to debug. For example, we could specify what objects we are looking for by using a predicate expression eg., objects of a specific class, or with specific instance variables values , and automatically explore the execution back and forth to find those objects. However, to the best of our knowledge, time-traveling debuggers do not support object-centric debugging and vice-versa.
Proposition: combining time-traveling and object-centric debugging. We argue that
enhancing object-centric debugging by time-traveling mechanisms would enable new
debugging tools (dedicated interfaces, requests, views...) that would improve the debugging
of object-oriented programs. In this paper, we illustrate our first probe combining both
techniques. We use our execution querying system named Time-Traveling Queries [
In the following, we illustrate the dificulties developers go through when they try to comprehend objects behavior during debugging. We explain how object-centric debugging and time-traveling debugging support these challenges, and their limitations. As an example, we use a test method from the Pharo 11 code base:
Listing 1: The split-join test of collections in Pharo 11.
S p l i t J o i n T e s t >> t e s t S p l i t O r d e r e d C o l l e c t i o n O n O r d e r e d C o l l e c t i o n s e l f a s s e r t : ( ( ( 1 to : 10) a s O r d e r e d C o l l e c t i o n ) s p l i t O n : ( ( 4 to : 5) a s O r d e r e d C o l l e c t i o n ) ) e q u a l s : {(1 to : 3) a s O r d e r e d C o l l e c t i o n . (6 to : 10) a s O r d e r e d C o l l e c t i o n } a s O r d e r e d C o l l e c t i o n
In this test, an OrderedCollection of 10 elements is split by another OrderedCollection with two elements. This operation is expected to produce a new OrderedCollection containing both left and right sides of the split operation (each side of the split is an OrderedCollection). The developer, trying to understand this execution, wants to obtain information about the behavior and state of instances of OrderedCollection during the execution of the test. The standard procedure is to step the execution until the desired object is instantiated. This potentially requires numerous and carefully executed steps before the observation of the desired object can take place. Moreover, the execution of this test produces several instances of OrderedCollection, and these instantiation calls are not immediately visible in the test code. It is dificult to track each object, as none of them is seemly stored in a variable. This makes such manual approach even more tedious.
Using an object-centric debugger, developers can improve over such approach by using specific breakpoints that halts the execution whenever a class is instantiated. With this technique, developers need to halt a certain number of times to reach the OrderedCollection of interest. Once the object of interest has been reached, developers can use object-centric breakpoints to observe the object’s behavior and the evolution of its state. One downside of this technique is that it might take many halts to reach the object of interest in the first place, and then several other object-centric breakpoints to observe a relevant information. If the developer accidentally misses that relevant information, then all this procedure has to be restarted from scratch.
By using a time-traveling debugger, we can enhance this approach by navigating back and forth in the execution. If developers miss the observation of one of the collections, or if they passed it and want to observe it again, they reverse the execution and look for that collection, without the need to redoing everything from the beginning.
Object-centric debugging and time-traveling debugging both provide enhancements over standard debugging tools on their own. We argue that they can complement each other to improve debugging further. In the following, we start to explore how these techniques can benefit from each other, what is required to enable this new joint approach and how could we materialize this approach into a tool.
In this section we present our debugger SeekerOC. We explain how it helps solving the dificulties identified by using debugging queries and new specialized tools.
Our debugger ofers a list of general purpose queries that can be conveniently executed from a context menu. We extended this menu with new queries to ease the task of identifying and tracking objects, as described next.
Figure 1 shows our debugger opened at the beginning of the execution of the code from Listing 1. To find all collections created during the execution of that code, we select the OrderedCollection string and we execute the query All instances creation of class named as selection from the context menu (Figure 1(a)). Once the query has been executed, the results are displayed in a table (Figure 1(b)). These results contain the complete list of all the OrderedCollection objects that are instantiated during the execution of the debugged program.
From the results table, we efortlessly have access to each one of these objects by right clicking the corresponding result item, and choosing the command inspect object about to be instantiated (Figure 1(c)). This command opens an inspector on the object corresponding to the selected result row, and shows the object state in the execution state from which we executed the query. If the object has not yet been instantiated, the execution is advanced to such event, so the object can be inspected.
Every result entry of TTQs includes a timestamp (the step number) of every registered event. Clicking in the step column of any result item will advance or reverse the execution, time-traveling to the registered timestamp. This feature makes queries results act as bookmarks of an execution, providing a practical and precise alternative to using breakpoints and tedious stepping operations for program exploration.
Pharo traditionally ofers a graphical utility for object inspection — a view that displays information about the state of an object, its API, and other useful information. During a SeekerOC debugging session, inspecting any object of the debugged execution will open an enhanced version of the Pharo Inspector.
This specialized inspector synchronizes with the time-traveling debugger to keep an updated view of the inspected object. Stepping the execution forward or backwards triggers updates of the displayed information. This inspector contains a menu for object-centric queries available for the inspected object (Figure 2): • Time travel to instantiation instruction.
• List all messages sent to the inspected object.
Every TTQ provides a set of timestamp-indexed results in the Query Results Table. Therefore, by clicking on the step column of every result item, we time-travel to the timestamp of each registered event, without the inconveniences of stepping or halting.
By using TTQs, the relevant debugging information of the execution is collected efortlessly. This information is now directly accessible from the Query Results Table, instead of requiring developers to go through the traditional manual debugging process.
We built our experimental object-centric prototype SeekerOC upon SeekerDebugger, our
queryable time-traveling debugger implemented for Pharo. SeekerDebugger provides
the base mechanism to perform general purpose Time-Traveling Queries[
Our work materializes an exploration step towards a new type of debugging tool: an object-centric time-traveling debugger, based on debugging queries. In our proposition, Time-Traveling Queries play the central role joining object-centric and time-traveling debugging. Querying an execution ofers a traced representation of it, granting easy access to objects. The time-traveling back-end ensures that the execution can be re-executed following the same trace. Therefore, if an object can be identified in such trace, it can be referenced in any re-execution of the program. This generates opportunities to explore object-centric debugging in an new joint debugging paradigm, enabling techniques and features previously unfeasible.
These opportunities open many questions. Are TTQs the only mechanism required to connect both techniques? If not, what are the required properties and/or mechanisms to build object-centric time-traveling debuggers? What precisely are the benefits of such debugger, and to what extent do they benefit to the debugging activity? In future work, we plan to investigate these questions by pursuing our implementation of object-centric TTQs and analyzing their requirements and efectiveness through empirical experiments.
Object-centric debugging and time traveling debugging have been the subject of research
in the recent years. However, and to the best of our knowledge, they have never been
combined to support each other. Here we discuss how some of these works relate to ours.
Object-centric debuggers. Object Miners [
Other work [
Time-traveling debuggers. Expositor [
Whyline [
This work is funded by the ANR project OCRE https://anr.fr/Projet-ANR-21-CE25-0004 and Inria.