Limitations of today’s Debuggers

Recently I found this talk on debugging in 2011. The speaker talks about problems of today's debuggers and how a new architecture, denoted as Time-Travel Debugging, can solve them. I provide an overview of the talk in this article, with my personal opinion on the topic.

The speaker describes at first the context in which debuggers were designed from late 70's till today:

• Programs are single threaded
• Execution flow is sequential
• Bugs are always reproducible
• Programs run for short periods of time

• Multithreading
• Flow of execution not 100% sequential
• Reproducing bugs is (very) tough
• Programs run for weeks/months/years

I agree on the first two arguments, although I would summarize both under multithreading, since multithreaded programs are already less than 100% sequential. The third statement is from my point of view dependent on the actual project (technologies and infrastructure). The final point is not specific for 2011 (today). Back in the days, developers also wrote programs with millions loc. Additionally to the mentioned requirements, I would add the following two:

• Distribution across multiple machines
• Development with different languages

The first requirement addresses applications that are distributed across multiple machines. Many debuggers allow remote debugging, but this is not the point here. What I want as a developer is a unified debugging view on my system. I should be able to step into (of course also step out, over etc.) a web-service on machine B from machine A. The tool should handle the the execution flow and update the UI accordingly. The other requirement deals with multi-language systems, developed with multiple languages. Not only with the rise of JVM languages are systems developed with multiple languages. Back in the days, Java EE developers used already multiple languages, such as Java and JSPs (both as a language), to develop their systems. Here, as a developer, I want a unified debugger which abstract from the process barriers and allows me to debug the whole system in the same context.

Vraný et al. describe in their paper an architecture for integrating multiple heterogenous debugger in a common UI. With their system, users can revisit the execution flow and control it. This is a good starting point for tackling the mentioned requirements, but not yet the last word on the subject.

In my next post I will provide an overview of the presented debugger prototype, which provides already the time-travelling feature.