Documentation

Find developer guides, API references, and tutorials to get started with time travel debugging, develop advanced troubleshooting skills, and learn how to integrate LiveRecorder and UDB into your application or workflow.

Time travel debugging in IntelliJ ¶

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 Run/Debug configuration from the Run/Debug Configurations dialog and press the Debug button to start debugging.

_images/rundebug.png

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.png

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.png

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/undo_buttons.png

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. (The Log Viewer window is an alternative way of doing the same thing)

Timestamps should ideally have millisecond accuracy but even these are only approximate so you might find that the resulting stack is just somewhere in the code that emitted the log line.

_images/logjump.png

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 › Tools › LiveRecorder › Timestamp patterns . If the timezone is not specified in the timestamp it defaults to the local timezone.

Step Across ¶

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.

Bookmarks ¶

LiveRecorder for Java allows you to set bookmarks in a recording to which you can later return. They are displayed in the TimeTravelBookmarks tool window ( View › Tool Windows › TimeTravelBookmarks ) as shown below:

_images/bookmarks.png

Use the START and END bookmarks to jump to the beginning or end of your application’s execution history.

Use the Add Bookmark button to add a bookmark at the current point in time in your application’s execution history. You can return to this point in time by clicking on the bookmark.

Bookmarks are automatically ordered by their place in the execution history and display the location as well as the bbcount .

Bookmarks are not persistent and only exist for the lifetime of the session.

If you press the control key and then hover over the bbcount cell, the bbcount will be copied to the clipboard. This can be useful when examining the same recording using udb .

Log Viewer ¶

As an alternative to the Log Jump window you can also open a log file in the LogViewer window ( View › Tool Windows › LogViewer ). If the log file contains a timestamp at the start of each line in one of the recognised formats, just clicking on that line will take you to the approximate location.

_images/logviewer.png

LiveRecorder for Java

  • Introduction
  • Getting started
  • Recording an application
  • Replaying a recording
  • Live Debugging
  • Start the debugger session
  • Forward and reverse execution
  • Other methods of navigation
  • Microservices
  • Recording test failures
  • System Requirements

Time-Travel Debugging Production Code

Loren

Loren Sands-Ramshaw

Developer Relations Engineer

In this post, I’ll give an overview of time-travel debugging (what it is, its history, how it’s implemented) and show how it relates to debugging your production code.

Normally, when we use debuggers, we set a breakpoint on a line of code, we run our code, execution pauses on our breakpoint, we look at values of variables and maybe the call stack, and then we manually step forward through our code’s execution. In time-travel debugging , also known as reverse debugging , we can step backward as well as forward. This is powerful because debugging is an exercise in figuring out what happened: traditional debuggers are good at telling you what your program is doing right now, whereas time-travel debuggers let you see what happened. You can wind back to any line of code that executed and see the full program state at any point in your program’s history.

History and current state

It all started with Smalltalk-76, developed in 1976 at Xerox PARC . ( Everything started at PARC 😄.) It had the ability to retrospectively inspect checkpointed places in execution. Around 1980, MIT added a “retrograde motion” command to its DDT debugger , which gave a limited ability to move backward through execution. In a 1995 paper, MIT researchers released ZStep 95, the first true reverse debugger, which recorded all operations as they were performed and supported stepping backward, reverting the system to the previous state. However, it was a research tool and not widely adopted outside academia.

ODB, the Omniscient Debugger , was a Java reverse debugger that was introduced in 2003, marking the first instance of time-travel debugging in a widely used programming language. GDB (perhaps the most well-known command-line debugger, used mostly with C/C++) added it in 2009.

Now, time-travel debugging is available for many languages, platforms, and IDEs, including:

  • Replay for JavaScript in Chrome, Firefox, and Node, and Wallaby for tests in Node
  • WinDbg for Windows applications
  • rr for C, C++, Rust, Go, and others on Linux
  • Undo for C, C++, Java, Kotlin, Rust, and Go on Linux
  • Various extensions (often rr- or Undo-based) for Visual Studio, VS Code, JetBrains IDEs, Emacs, etc.

Implementation techniques

There are three main approaches to implementing time-travel debugging:

  • Record & Replay : Record all non-deterministic inputs to a program during its execution. Then, during the debug phase, the program can be deterministically replayed using the recorded inputs in order to reconstruct any prior state.
  • Snapshotting : Periodically take snapshots of a program’s entire state. During debugging, the program can be rolled back to these saved states. This method can be memory-intensive because it involves storing the entire state of the program at multiple points in time.
  • Instrumentation : Add extra code to the program that logs changes in its state. This extra code allows the debugger to step the program backwards by reverting changes. However, this approach can significantly slow down the program’s execution.

rr uses the first (the rr name stands for Record and Replay), as does Replay . WinDbg uses the first two, and Undo uses all three (see how it differs from rr ).

Time-traveling in production

Traditionally, running a debugger in prod doesn’t make much sense. Sure, we could SSH into a prod machine and start the process handling requests with a debugger and a breakpoint, but once we hit the breakpoint, we’re delaying responses to all current requests and unable to respond to new requests. Also, debugging non-trivial issues is an iterative process: we get a clue, we keep looking and find more clues; discovery of each clue is typically rerunning the program and reproducing the failure. So, instead of debugging in production, what we do is replicate on our dev machine whatever issue we’re investigating and use a debugger locally (or, more often, add log statements 😄), and re-run as many times as required to figure it out. Replicating takes time (and in some cases a lot of time, and in some cases infinite time), so it would be really useful if we didn’t have to.

While running traditional debuggers doesn’t make sense, time-travel debuggers can record a process execution on one machine and replay it on another machine. So we can record (or snapshot or instrument) production and replay it on our dev machine for debugging (depending on the tool, our machine may need to have the same CPU instruction set as prod). However, the recording step generally doesn’t make sense to use in prod given the high amount of overhead—if we set up recording and then have to use ten times as many servers to handle the same load, whoever pays our AWS bill will not be happy 😁.

But there are a couple scenarios in which it does make sense:

  • Undo only slows down execution 2–5x , so while we don’t want to leave it on just in case, we can turn it on temporarily on a subset of prod processes for hard-to-repro bugs until we have captured the bug happening, and then we turn it off.
  • When we’re already recording the execution of a program in the normal course of operation.

The rest of this post is about #2, which is a way of running programs called durable execution .

Durable execution

What’s that.

First, a brief backstory. After Amazon (one of the first large adopters of microservices) decided that using message queues to communicate between services was not the way to go (hear the story first-hand here ), they started using orchestration. And once they realized defining orchestration logic in YAML/JSON wasn’t a good developer experience, they created AWS Simple Workfow Service to define logic in code. This technique of backing code by an orchestration engine is called durable execution, and it spread to Azure Durable Functions , Cadence (used at Uber for > 1,000 services ), and Temporal (used by Stripe, Netflix, Datadog, Snap, Coinbase, and many more).

Durable execution runs code durably—recording each step in a database, so that when anything fails, it can be retried from the same step. The machine running the function can even lose power before it gets to line 10, and another process is guaranteed to pick up executing at line 10, with all variables and threads intact.[^1] It does this with a form of record & replay: all input from the outside is recorded, so when the second process picks up the partially-executed function, it can replay the code (in a side-effect–free manner) with the recorded input in order to get the code into the right state by line 10.

Durable execution’s flavor of record & replay doesn’t use high-overhead methods like software JIT binary translation , snapshotting, or instrumentation. It also doesn’t require special hardware. It does require one constraint: durable code must be deterministic (i.e., given the same input, it must take the same code path). So it can’t do things that might have different results at different times, like use the network or disk. However, it can call other functions that are run normally ( “volatile functions” , as we like to call them 😄), and while each step of those functions isn’t persisted, the functions are automatically retried on transient failures (like a service being down).

Only the steps that require interacting with the outside world (like calling a volatile function, or calling sleep('30 days') , which stores a timer in the database) are persisted. Their results are also persisted, so that when you replay the durable function that died on line 10, if it previously called the volatile function on line 5 that returned “foo”, during replay, “foo” will immediately be returned (instead of the volatile function getting called again). While yes, it adds latency to be saving things to the database, Temporal supports extremely high throughput (tested up to a million recorded steps per second). And in addition to function recoverability and automatic retries, it comes with many more benefits , including extraordinary visibility into and debuggability of production.

Debugging prod

With durable execution, we can read through the steps that every single durable function took in production. We can also download the execution’s history, checkout the version of the code that’s running in prod, and pass the file to a replayer (Temporal has runtimes for Go, Java, JavaScript, Python, .NET, and PHP) so we can see in a debugger exactly what the code did during that production function execution. Read this post or watch this video to see an example in VS Code.[^2]

Being able to debug any past production code is a huge step up from the other option (finding a bug, trying to repro locally, failing, turning on Undo recording in prod until it happens again, turning it off, then debugging locally). It’s also a (sometimes necessary) step up from distributed tracing.

💬 Discuss on Hacker News , Reddit , Twitter , or LinkedIn .

I hope you found this post interesting! If you’d like to learn more about durable execution, I recommend reading:

  • Building reliable distributed systems
  • How durable execution works

and watching:

  • Introduction to Temporal
  • Why durable execution changes everything

Thanks to Greg Law, Jason Laster, Chad Retz, and Fitz for reviewing drafts of this post.

[^1]: Technically, it doesn’t have line-by-line granularity. It only records certain steps that the code takes—read on for more info ☺️. [^2]: The astute reader may note that our extension uses the default VS Code debugger, which doesn’t have a back button 😄. I transitioned from talking about TTD to methods of debugging production code via recording, so while Temporal doesn’t have TTD yet, it does record all the non-deterministic inputs to the program and is able to replay execution, so it’s definitely possible to implement. Upvote this issue or comment if you have thoughts on implementation!

Time Travel Debugging

Do you have a flaky test showing up rarely? Do you sometimes skip to the next breakpoint too early and must restart? Do you sometimes wish you could see what your application state was 1 second ago? Or do you sometimes wish you could see who has modified a field of a class just before "now"?

If the answer is yes to some of these questions, then this blog post might be for you!

an image showing the debug view with new buttons added by the time travel debug plugin

A few weeks ago I wanted to learn some new technology stacks. For that I brewed my coffee, sat down in front of my PC and... did not learn. At least not, what I initially decided to do. I have started the PC, WSL2, IntelliJ Idea, Docker and was almost there.

But instead of programming I've opened up the plugins window. While browsing not only 10 minutes, or 30 minutes, I've spent at least one hour scrolling through the plethora of plugins.

And there I've seen it. Time Travel Debugging. As a Plugin. Huh, what's that ?

image of the time travel debugging plugin in the plugins window

Why have I never heard about time travel debugging? Chats with colleagues have sparked their interest, too. The videos of undo.io explaining what their tool does, that looks like a feature too good to be true.

The Goal Of This Blogpost

  • We'll build a pipeline with failsafe, jacoco and live-recorder, recording test-failures.
  • I'll show some errors I've encountered at the end of the blogpost, because that is some major point I missed while exploring the plugin / tool.

Table of Contents

Prerequisites, what is time travel debugging, what is live recorder, what is live replay.

  • Most Prominent Features Of Live Recorder
  • While Normally Debugging
  • Manually Recording A Test (so you could share the problem with your colleagues)
  • As A Recorder For Failing Tests In Combination With Jacoco
  • Problems Faced With Live Recorder

The Drawbacks

  • A trial license for live-recorder is required undo.io/getjava
  • JDK 11 (I'm using azul zulu) - (JDK 17 did not work)
  • IntelliJ IDEA 2021.3.* (IDEA 2022.* did not work)
  • Ubuntu / Linux machine (WSL2 did not work)
  • A sample project, you wish to time travel debug

It's quite simple: you can jump back in time. Jump back to the breakpoints before, including the application state at this point in time.

Such a technical answer, as I've stated at the very top of this post, there are some cool goals you can reach:

  • catch that one flaky test and how the test suite ended there
  • see who has modified a field before this call
  • just add new breakpoints
  • explore the codebase and how everything is tied together

Live Recorder is a tool created by undo.io. Attached to your Java Application as an agent it'll record the JVM state into a file with the postfix filename .undo.

Live Replay comes with Live Recorder. It's an additional application which loads your recording file. Also, a port is opened, by default port 9000 . Finally, you attach IntelliJ Idea to this port and start debugging forwards and backwards.

Most prominent Features of Live Recorder.

There seems to be 3 major use-cases:

  • Debug an application, as you would normally, just with the ability to jump back in time.
  • Remotely debug an application, also with the ability to jump back in time
  • Replay a recording by attaching IntelliJ to a started Live Replay session

How to use Live Recorder

Let's dive into this topic, but first let's download all the required tools and obtain the information.

  • Register for a trial: undo.io/getjava

image of confirmation mail by undo.io showing the link to the required data

  • unzip the data
  • Install IntelliJ Idea 2021.3.* IntelliJ other Versions
  • Install the Time Travel Debugging Tool in IntelliJ
  • Open the Settings "Build, Execution, Deployment > Debugger > LiveRecorder"

image of the plugins settings file

  • Create a new Maven Project, or use an existing application using maven
  • !!IMPORTANT!! Make sure, that the JAVA_HOME variable points to the same version you run your project (compare "Project Settings" JDK with javac --version)

Now we're set up. Let's debug our first application:

How to use Live Recorder While Debugging Normally

Let's simply debug an application as we've done it a million times already

select the correct type of run configuration, i.e. : LiveRecorder -> Application

How To Manually Record And Replay A Test

Recording the application is as simple as adding some JVM Arguments to the execution of the application. Better said: we need to pass an agent to the VM.

  • create a simple test
  • run the test once
  • edit the run configuration for the test

show the VM Arguments input field

Now that we've recorded the test, let's replay it.

  • add some breakpoints to your test
  • rename the file for ease of use to first-recording.undo
  • now start the live replay server via console

terminal output showing that the application defaults to port 9000

  • press the debug button

Some Additional Information :

  • IntelliJ froze multiple times, you can kill the lr4j_replay application with ctrl-c , which should give you back your control.

Let's go to the last step, where we stitch everything together - integrating Live Recorder into our CI/CD

Record Failing Tests with Surefire and Jacoco

Integrating Live Recording with failing tests in Surefire is described in the documentation , but there are some problems around surefire / failsafe with the argLine. The problem with jacoco/surefire/failsafe can be found here http://www.devll.org/blog/2020/java/jacoco-argline.html Also, the documentation of undo.io is stuck on JUnit 4. I'll show you how to transfer the Rule to the JUnit 5 equivalent.

The following code excerpt is a minimum example for jacoco + surefire + junit 5.

Now that we have configured the pom with the required dependencies but also with the correct surefire argLine we can proceed with configuring the last step: Setting environment variables for the agent, so that the agent knows when to save the recording and when not:

  • create the following Listener for your JUnit Tests:
  • add an Extension Hook to your test class:
  • run your tests with mvn clean verify
  • after the execution you should see two files: "failingTest.undo" and "anotherFailingTest.undo"
  • if you disable the failing tests, you should see the coverage reports from jacoco.
  • Success. You have integrated Jacoco & Time Travel Debugging in your CI Pipeline

Congratulations, you've successfully automated the recording of your failing tests. Partly at least.

Problems faced with Live Recorder

I had a lot of errors and nearly stopped evaluating the tool. Let me shortly explain why: There is no clear indication what does not work. There are some errors not clearly stating what's wrong. The application just freezes IntelliJ and I need to either restart or find some other way.

Also, sometimes it looked like it's working, but it didn't. Trying to find out what's going on.

On my journey I've

  • switched from Spring Boot to a simple Project
  • from JDK 17 to JDK 11
  • from IntelliJ Idea 2022.* to Idea 2021.3.*
  • from WSL2 to another pc running Ubuntu locally
  • encountered further problems, e.g. missing debug symbols in the default openjdk

before I even saw that the tool can do, what it's promising. All that while always getting multiple freezes. This was really discouraging.

If you see one of the following problems, you might need to change your environment, also:

terminal output of the recorder freezing IntelliJ Idea

With these exceptions you're just faced with: it's not working, and I don't know why. Good luck googling these issues!

Let's wrap this topic up with annoyances I've encountered on my way.

  • The pricing is not public.
  • There is no section with common errors in their documentation. And let me tell you, I've encountered a lot of errors.
  • I did not find any resources except the official ones. I assume that this is the lack of an existing community / users behind the product.

Time Travel Debugging is another mighty tool in our developer tool belt. It's still rough on some edges, but if configured correctly, it might save you a lot of time debugging. Also - as learned in my bachelors told by one of my professors:

'you can have the best product. If no-one knows that your product exists, it won´t succeed'

New technology and games (programming) are his passion. Throws away 10 hours of life to fix this one annoying issue, scarcily encountered.

Cookies Heading Help Text

Cookies Help Text

DEV Community

DEV Community

Playwright end to end Testing profile image

Posted on May 5, 2023 • Updated on May 10, 2023

Playwright's UI Mode - watch mode and time travel debugging

Are you looking for a more efficient way to execute and debug your end to end tests? Look no further than Playwright's UI Mode . In this guide, we'll explore the features of Playwright's UI Mode and show you how to take advantage of them for your test automation needs. UI mode is only available when using Playwright with Node.js and not with Python, Java or C#.

What is UI Mode?

UI Mode is a powerful graphical user interface that provides a comprehensive trace of each of your tests. With UI Mode, you can explore, run, and debug your tests effortlessly with its time-traveling capabilities. The user-friendly interface enables you to view detailed test results, including logs, DOM snapshots, and trace information.

In addition, UI Mode comes equipped with watch mode, which allows you to monitor any of your tests and automatically rerun them on every code change, providing an optimal developer experience.

Overall, Playwright's UI Mode provides a comprehensive, user-friendly testing experience that allows you to identify and fix issues with your tests quickly and easily.

How to Use UI Mode?

To use UI Mode, you need to run the following command:

When you launch UI Mode, you'll see a list of all your test files. To run your tests, you have several options: click the triangle icon in the sidebar to run all of your tests, hover over a test file's name, and click on the triangle next to it to run a single test, a block of tests, or an entire test file.

running your tests in UI mode

Filtering Tests in UI Mode

You can filter tests by text or @tag, by passed, failed, or skipped tests, and by projects as set in your playwright.config file. If you are using project dependencies, make sure to run your setup tests first before running the tests that depend on them. The UI Mode will not take into consideration the setup tests, so you will have to manually run them first.

filtering tests in UI mode

Viewing Test Traces

Traces provide detailed information about each test that has been executed. You can access the trace results by clicking on any of the individual test names. By examining the trace results, you can identify the cause of any failures or errors that occurred during the test run and take appropriate action to address them.

viewing test traces in ui mode

Actions and Metadata

The Actions tab provides valuable insights into your test execution. You can view the specific locator used for each action and the time taken to complete it. When you hover over each action, you can observe the changes in the DOM snapshot. Additionally, you can navigate backward and forward in time, and click on any action to inspect and debug it. The Before and After tabs allow you to visually track the changes that occurred before and after each action.

Adjacent to the Actions tab, you'll find the Metadata tab. This tab provides you with additional information on your test, such as the browser used, viewport size, test duration, and more.

actions and metadata in ui mode

Source, Console, Log, and Network

When hovering over a test action, its corresponding source code is highlighted below. To view the entire test's source code, click the "source" tab. Console logs and network logs for each action can be accessed by clicking the "console" and "network" tabs, respectively.

source console long and network in ui mode

Pop Out and Inspect the DOM

To enhance your debugging experience, you can pop out the DOM snapshot by clicking the dedicated icon located above it. This will open the snapshot in a separate window where you can inspect HTML, CSS, and more using the browser DevTools. You can then go back to UI Mode and pop out another action's snapshot to compare or debug them side by side.

pop out and inspect dom in ui mode

Timeline View

At the top of the trace, you can see a timeline view of each action of your test. Hover back and forth to see an image snapshot for each action.

timeline view in ui mode

Pick Locator

One of the most important parts of automated testing is identifying the elements on the page that you want to interact with. The Pick Locator feature in Playwright's UI Mode makes this process much easier by allowing you to easily select an element and retrieve its locator.

To use Pick Locator, simply click on the Pick Locator button in the UI Mode toolbar. This will activate the feature and highlight all the elements on the page as you hover over them. Once you click on a element the corresponding locator will be displayed in the Pick Locator field. Click on the copy button and then paste the locator into your test.

pick locator in ui mode

Watch Mode is another useful feature in Playwright's UI Mode that allows you to automatically re-run your tests as you make changes to your code. This can be particularly helpful when you are working on a large test suite and want to quickly test a change you've made without having to manually re-run the tests every time.

To use Watch Mode, simply click on the Eye icon next to the name of the test you want to watch. This will activate the feature and automatically re-run the test whenever you make changes to its code. You can watch multiple tests at the same time by clicking on the Eye icon next to each test, or you can watch all the tests in your test suite by clicking on the Eye icon at the top of the sidebar.

If you are using VS Code, you can easily open the test file in the editor by clicking on the File icon next to the Eye icon. This will open the test file in VS Code and take you directly to the line of code that corresponds to the test step you are currently watching.

watch mode in ui mode

In conclusion, Playwright's UI Mode offers a powerful set of tools for exploring, running, and debugging your automated tests. The time travel experience, complete with watch mode, filtering, and tracing, allows you to quickly identify and fix issues in your test code, while the Pick Locator feature simplifies the process of selecting and interacting with elements on the page. Whether you're a seasoned automated testing pro or just getting started with test automation, Playwright's UI Mode is definitely worth checking out.

Useful links

  • UI Mode docs
  • UI Mode video
  • Playwright on Discord
  • Star us on GitHub

Top comments (6)

pic

Templates let you quickly answer FAQs or store snippets for re-use.

toddbradley profile image

  • Location Denver, CO, USA
  • Education University of Colorado - twice!
  • Work Test Automation Architect at a small company
  • Joined Jan 7, 2023

With Python, playwright gives the error "error: unknown command 'test'". I suspect this feature only works with one of the four languages Playwright supports. If so, it's probably worth mentioning in the article.

debs_obrien profile image

  • Location Spain
  • Education Frontend Tech Degree at OpenClassrooms, Fullstack Tech Degree at Treehouse
  • Work Senior Technical Program manager at Microsoft
  • Joined Aug 15, 2019

thanks for recommendation. updated the article to reflect that it only works when using playwright in node.js and not with other languages

vinayb profile image

  • Joined Dec 19, 2023

Playwright UI does not show the tests even though the tests are in proper folder as mentioned in the config file. It always goes Infinite loading… . Here the playwright Ui is hosted as an application and it is running in a pod of a node of kube Cluster

ysegura8802 profile image

  • Location La Habana, Cuba
  • Education Universidad de las Ciencias Informáticas (UCI)
  • Pronouns Yordani
  • Work QA Automation
  • Joined May 22, 2023

Hi Debbie. I am writing to see if you can help me with any ideas. I'm trying to implement some tests with Playwright but I need to pass two factor authentication. Is there a way to do it with the tool?

Greetings. Yordani!!!

deniscoelhow profile image

  • Joined May 5, 2023

I'm using cucumber with Playwright at my project. Is there any way to run cucumber tests with playwright in this --ui mode? I tried running it in my project, but it didn't work.

i am afraid not at the moment. but you can fill out a feature request on GitHub

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

fpaghar profile image

ER Diagram Sample for Ecommerce Project

Fatemeh Paghar - Mar 9

_jaydeepkarale profile image

How to Scroll to an Element in Playwright

Jaydeep Karale - Mar 9

lucaschitolina profile image

I don't get the point of Golang - That's why I need help

Lucas Chitolina - Mar 5

kdhamric profile image

The Lord of Playwright: The Two Traces

Ken Hamric - Feb 8

DEV Community

We're a place where coders share, stay up-to-date and grow their careers.

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Time Travel Debugging - Overview

  • 1 contributor

Time travel debugging logo featuring a clock.

What is Time Travel Debugging?

Time Travel Debugging is a tool that allows you to capture a trace of your process as it executes and then replay it later both forwards and backwards. Time Travel Debugging (TTD) can help you debug issues easier by letting you "rewind" your debugger session, instead of having to reproduce the issue until you find the bug.

TTD allows you to go back in time to better understand the conditions that lead up to the bug and replay it multiple times to learn how best to fix the problem.

TTD can have advantages over crash dump files, which often miss the state and execution path that led to the ultimate failure.

In the event you can't figure out the issue yourself, you can share the trace with a coworker and they can look at exactly what you're looking at. This can allow for easier collaboration than live debugging, as the recorded instructions are the same, whereas the address locations and code execution will differ on different PCs. You can also share a specific point in time to help your coworker figure out where to start.

TTD is efficient and works to add as little as possible overhead as it captures code execution in trace files.

TTD includes a set of debugger data model objects to allow you to query the trace using LINQ. For example, you can use TTD objects to locate when a specific code module was loaded or locate all of the exceptions.

Screenshot of WinDbg with Time Travel Debugging command and three timelines.

Requirements

Time Travel Debugging is integrated with WinDbg , providing seamless recording and replay experience.

To use TTD, you need to run the debugger elevated. Install WinDbg using an account that has administrator privileges and use that account when recording in the debugger. In order to run the debugger elevated, select and hold (or right-click) the WinDbg icon in the Start menu, and then select More > Run as Administrator.

The recording may contain personally identifiable or security related information

The created trace file that contains the recording may contain personally identifiable or security related information, including but not necessarily limited to file paths, registry, memory or file contents. Exact information depends on target process activity while it was recorded. Be aware of this when sharing recording files with other people.

TTD.exe command line recording utility

In addition to recording traces in the WinDbg UI, there is a TTD.exe command line utility available to record a trace.

You may have scenarios where only the TTD command line recorder is required: recording on a PC without installing the debugger, advanced recording scenarios, test automation, etc. In these scenarios you can install just the TTD command line recorder through a URL. For more information, see Time Travel Debugging - TTD.exe command line utility .

Comparison of Debugging Tools

This table summarizes the pros and cons of the different debugging solutions available.

Video Training

To learn more about TTD see these videos.

Defrag Tools 185 - Ivette and JamesP go over the basics of TTD and demo some features in WinDbg

Defrag Tools 186 - Jordi and JCAB demo more great features of TTD in WinDbg

CppCon (YouTube) - Jordi, Ken and JamesM presented TTD in WinDbg at CppCon 2017

Trace file basics

Trace file size.

The trace file can get big and the user of TTD needs to make sure that there is adequate free space available. If you record a program for even a few minutes, the trace files can quickly grow to be several gigabytes. TTD does not set a maximum size of trace files to allow for complex long running scenarios. Quickly re-creating the issue, will keep the trace file size as small as possible.

Trace and index files

A trace file ( .run ) stores the code execution during recording.

Once the recording is stopped, an index file ( .idx ) is created to optimize access to the trace information. Index files are also created automatically when WinDbg opens trace files.

Index files can also be large, typically twice as large as the trace file.

You can recreate the index file from the trace file using the !tt.index command.

Recording errors and other recording output is written to a WinDbg log file.

All of the output files are stored in a location configured by the user. The default location is in the users document folder. For example, for User1 the TTD files would be stored here:

For more information on working the trace files, see Time Travel Debugging - Working with trace files .

Things to look out for

Anti-virus incompatibilities.

You may encounter incompatibilities because of how TTD hooks into process to record them. Typically issues arise with anti-virus or other system software that is attempting to track and shadow system memory calls. If you run into issues of with recording, such as an insufficient permission message, try temporarily disabling any anti-virus software.

Other utilities that attempt to block memory access, can also be problematic, for example, the Microsoft Enhanced Mitigation Experience Toolkit.

Another example of an environment that conflicts with TTD, would be the electron application framework. In this case the trace may record, but a deadlock or crash of the process being recorded is also possible.

User mode only

TTD currently supports only user mode operation, so tracing a kernel mode process is not possible.

Read-only playback

You can travel back in time, but you can't change history. You can use read memory commands, but you can't use commands that modify or write to memory.

System Protected Processes

Some Windows system protected processes, such as Protected Process Light (PPL) process are protected, so the TTD cannot inject itself into the protected process to allow for the recording of the code execution.

Performance impact of recording

Recording an application or process impacts the performance of the PC. The actual performance overhead varies based upon the amount and type of code being executed during recording. You can expect about a 10x-20x performance hit in typical recording scenarios. Sometimes there will not be a noticeable slowdown but for more resource intensive operations (i.e. File Open dialog) you can see the impact of recording.

Trace file errors

There are some cases where trace file errors can occur. For more information, see Time Travel Debugging - Troubleshooting .

Advanced Features of Time Travel Debugging

Here's some of the most notable TTD advanced features.

Timelines are a visual representation of events that happen during the execution. These events can be locations of: breakpoints, memory read/writes, function calls and returns, and exceptions. For more information about timelines, see WinDbg - Timelines .

Debugger data model support

  • Built in data model support - TTD includes data model support. Using LINQ queries to analyze application failures can be a powerful tool. You can use the data model window in WinDbg to work with an expandable and browsable version of ‘dx’ and ‘dx -g’, letting you create tables using NatVis, JavaScript, and LINQ queries.

For general information about the debugger data model, see WinDbg - Data model . For information about working with the TTD debugger object model, see Time Travel Debugging - Introduction to Time Travel Debugging objects .

Scripting support

  • Scripting Automation - Scripting support for JavaScript and NatVis allows for the automation of problem investigation. For more information, see Time Travel Debugging - JavaScript Automation .

For general information about working with JavaScript and NatVis, see WinDbg - Scripting .

TTD.exe Command line utility

The TTD.exe command line utility to record traces is available. For more information, see Time Travel Debugging - TTD.exe command line utility .

Managed code TTD support

You can use the SOS debugging extension (sos.dll) running in 64 bit mode to debug managed code using TTD in WinDbg. For more information, see Debugging Managed Code Using the Windows Debugger .

Getting started with TTD

Review these topics to record and replay a trace file as well as for information on working with trace files and troubleshooting.

  • Time Travel Debugging - Record a trace
  • Time Travel Debugging - Replay a trace
  • Time Travel Debugging - Working with trace files
  • Time Travel Debugging - Troubleshooting
  • Time Travel Debugging - Sample App Walkthrough

These topics describe additional advanced functionality in time travel debugging.

  • Time Travel Debugging - Introduction to Time Travel Debugging objects
  • Time Travel Debugging - JavaScript Automation

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

IMAGES

  1. Time Travel Debug for Java

    time travel debug for java

  2. Time Travel Debugging

    time travel debug for java

  3. 4 Effective Debugging Techniques Every Java Developer Should Know

    time travel debug for java

  4. Introduction to advanced time travel debugging. WinDBG, can step

    time travel debug for java

  5. Time Travel Debugging by Ozcode

    time travel debug for java

  6. Java Debugging: Using Tracing To Debug Applications

    time travel debug for java

VIDEO

  1. ‼️ TIME TRAVEL ⌚ SEASON 2

  2. JAVA ESCAPE ft. Taro Watanabe

  3. Campursari Pop Java the most pleasant to listen and the most popular, suitable for resting friends

  4. Campursari Pop Java is very nice to listen when relaxing

  5. Худший спавн 5-1

  6. Make a simple GUI Digital Clock showing time and date using Java.

COMMENTS

  1. Time Travel Debug for Java

    Integrates LiveRecorder for Java - a powerful Time Travel Debugger for Linux based Java applications. Requires an existing copy of LiveRecorder for Java 6.12 later, or...

  2. Time Travel Debugging for Linux C/C++ and Java ¦ Undo

    Save time diagnosing the root causes of new regressions, flaky tests, and customer-reported issues - cut debugging time by 50 - 80%. Diagnose even the hardest of bugs, including memory corruptions and race conditions. Travel forward and backward in time to inspect program state - get to any point in the program's execution history to ...

  3. Time Travel Debug for Java in IntelliJ

    Demo: debugging a ConcurrentModificationException using time travel debugging in IntelliJ. More information on: https://undo.io/solutions/products/java/

  4. Time travel debugging in GDB

    Time travel debugging (also sometimes called reversible debugging) is a handy feature of some debuggers that allows you to step back through the execution of a program and examine the data prior to an exception being thrown or a breakpoint being reached (as opposed to only being able to view data at that time and onwards).

  5. 6 Things You Need to Know About Time Travel Debugging

    What is Time Travel Debugging? Time travel debugging (aka reverse debugging) enables developers to record all program activities at runtime (every memory access, every computation, and every call to the operating system), and then rewind and replay to inspect the program state. This huge amount of data can be described using a powerful metaphor: the ability to travel backward in time (and ...

  6. Time travel debugging in IntelliJ

    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 ...

  7. Time Travel Debugging

    Debuggers can call functions in your programs directly and tell you what they returned — how does this interact with time travel…. Mark Williamson. Sep 13, 2022. Hello, Java World. Hello ...

  8. Time-Travel Debugging Production Code

    ODB, the Omniscient Debugger, was a Java reverse debugger that was introduced in 2003, marking the first instance of time-travel debugging in a widely used programming language. GDB (perhaps the most well-known command-line debugger, used mostly with C/C++) added it in 2009. Now, time-travel debugging is available for many languages, platforms ...

  9. Time Travel Debugging Java Applications

    Speaker: Greg LawRecorded: 2021-03-2400:00:00 Intro00:03:10 The Talk01:06:20 Q&ATime-travel debugging gives you programming superpowers. Capture a machine-le...

  10. Time travel debugging

    Time travel debugging or time traveling debugging is the process of stepping back in time through source code to understand what is happening during execution of a computer program. Typically, debugging and debuggers, tools that assist a user with the process of debugging, allow users to pause the execution of running software and inspect the current state of the program.

  11. Time Travel Debug in VS Code

    We're happy to announce that time travel debugging is now available in Visual Studio Code (VS Code) via the Time Travel Debug for C/C++ plugin.. Time Travel Debug for C/C++ places time travel debugging capabilities at the fingertips of developers using VS Code. The technology is based on the UDB time travel debugger.. With this plugin, developers can now travel forward and backward through ...

  12. Videobug

    Hello All, I am building a time travel debugger tool for Java. It lets you trace your past code executions line by line in your IntelliJ IDE. It works on localhost and cloud deployments. We are releasing the localhost debugger - it works completely offline.

  13. TimeTravel Debugging

    The killer feature for JS/TS platforms. If you are building a JavaScript/TypeScript based platform, time-travel debugging is a killer feature. Users add breakpoints, then can step-through to see the internal state change line-by-line. This lets devs move fast and fix things. But more importantly it's a delightful developer experience.

  14. Time-Travel Debugging Production Code

    ODB, the Omniscient Debugger, was a Java reverse debugger that was introduced in 2003, marking the first instance of time-travel debugging in a widely used programming language. GDB (perhaps the most well-known command-line debugger, used mostly with C/C++) added it in 2009. Now, time-travel debugging is available for many languages, platforms ...

  15. Time Travel Debugging

    Finally, you attach IntelliJ Idea to this port and start debugging forwards and backwards. Most prominent Features of Live Recorder. There seems to be 3 major use-cases: Debug an application, as you would normally, just with the ability to jump back in time. Remotely debug an application, also with the ability to jump back in time

  16. What is the principle of "Time Travel Debugger"?

    Time travel debugging is also known as reverse debugging.In layman terms, you can debug the same lines again and again (without stopping/restarting the app). For example, you're debugging a method which threw an exception at line 10, to find the cause of exception you can again execute that method from a prior point let's say line 4 without restarting the complete debugging process. it's all ...

  17. Time Travel Debugger

    The Time Travel Debugger plugin provides support to debug TEA applications that use TEA-bag library. more... Email. Source Code. License. What's New. Plugin Versions. Initial EAP version with basic debugging and rendering support. more... Mar 14, 2024. Version 57ecc8-SNAPSHOT. Rating & Reviews.

  18. Technical Paper: Time Travel Debugging

    Time travel debugging is really powerful for: Any bug where time passes between the bug occurring and the symptoms presenting themselves, i.e. assertion failures, segmentation faults, or simply bad results being produced. ... Go, and Java software can now save a huge amount of time diagnosing the root causes of new regressions, legacy bugs, and ...

  19. Using our tools to fix our own bugs

    How Undo uses time travel debugging as part of the CI (Continuous Integration) test and development loop. This is the story of how we quickly found and investigated a flaky failure in our CI system…

  20. Playwright's UI Mode

    With UI Mode, you can explore, run, and debug your tests effortlessly with its time-traveling capabilities. The user-friendly interface enables you to view detailed test results, including logs, DOM snapshots, and trace information. In addition, UI Mode comes equipped with watch mode, which allows you to monitor any of your tests and ...

  21. Time Travel Debugging

    LiveRecorder - Java; Technical Paper: Time Travel Debugging; Solutions. Solutions; Use Case. Development & Test (C/C++/Java) Development & Test (C/C++/Java) Industries. Financial Services; Data management; Electronic Design Automation (EDA) Networking & Telecoms; Aerospace and Defense; Boost Developer Productivity. Reduce debug cycles down to ...

  22. Time Travel Debugging

    Time Travel Debugging is a tool that allows you to capture a trace of your process as it executes and then replay it later both forwards and backwards. Time Travel Debugging (TTD) can help you debug issues easier by letting you "rewind" your debugger session, instead of having to reproduce the issue until you find the bug. TTD allows you to go ...

  23. Why It's Time To Debug Different With Time Travel Debugging

    With UDB, developers can simplify troubleshooting by deterministically recording and replaying a program's behavior. UDB gives developers the ability to time travel backward (and forward) in the code execution to the origin of the failure without repetitive guesswork, restarts and stops. Time travel debugging is a game changer!