Time travel debugging in IntelliJ

Setup

If you’re replaying a recording, use the lr4j_replay tool.

Or if you’re debugging remotely, launch your application on the remote machine supplying the LiveRecorder agents on the java command-line.

Consider adding breakpoints and/or watchpoints before starting the debugger session since your application or recording will start running as soon as you press the Debug button.

Start the debugger session

Choose a LiveRecorder Run/Debug configuration from the Run/Debug Configurations dialog and press the Debug button to start debugging.

_images/rundebug.png

Note

Refer to Replaying a recording or Live Debugging if you haven’t already created a LiveRecorder Run/Debug configuration.

While your application is running, you can’t interact with it or examine application state. You can only Pause, Stop or Rerun your application. See IntelliJ tips for more info.

_images/running.svg

Once your application is suspended due to hitting a breakpoint or watchpoint, you can examine variables and the contents of the stack and evaluate arbitrary expressions. Refer to the IntelliJ documentation for details. You can’t alter variables while time-travel debugging, since doing so would likely change the future execution of the application and cause the timelines to diverge.

Forward and reverse execution

You can use the familiar Step Over, Step Into, Force Step Into, Step Out and Run to Cursor buttons to step the application forwards, or the Resume button to run the application forwards until it hits a breakpoint or watchpoint.

_images/forward.svg

LiveRecorder for Java adds the Reverse Step Out, Reverse Step Into and Reverse Step Over buttons, which you can use to step the application backwards, and the Resume Back button to run your application backwards until it hits a breakpoint or watchpoint.

_images/backward.svg

Other methods of navigation

Use the Undo button to undo the effects of the last button that changed the time in your application’s execution history.

Use the Log Jump button to jump to a wall-clock time in your application’s execution history. This is useful when you’ve identified a line of interest in a log file: in this case copy the timestamp from the log file and paste it into the Log Jump dialog to jump directly to the point in time in your application’s execution history where it emitted that log line.

Use the Step Across and Step Across Back buttons to step between two of the services that comprise a microservice-based application. Step Across jumps to the point in time in another service’s execution history when it received the next API call made by this service. Step Across Back jumps to the point in time in another service’s execution history when it last made an API call to this service. Refer to Microservices for more information.

_images/jump.svg

Note

The Log Jump feature recognises timestamps in many standard time formats produced by common logging frameworks including Log4j, Logback and java.util.logging. You can add other time formats under Settings › Build, Execution, Deployment › Debugger › LiveRecorder › Timestamp patterns.

Note

If the timestamp that you supply doesn’t include a timezone indication, LiveRecorder interprets the time using a default timezone, which is UTC by default. If LiveRecorder’s default timezone doesn’t match your application’s actual timezone then Log Jump won’t take you to the correct point in your application’s execution history. You can change LiveRecorder’s default timezone in Settings › Build, Execution, Deployment › Debugger › LiveRecorder › Log jump timezone.