Time-Travel Debugging for JavaScript/HTML Applications

Download this episode

Download Video

Description

Have you ever set a breakpoint a few statements too late, or accidentally stepped over the function call that you wanted to step into, and wished that you could just reverse-execute the program in the debugger? This video from Microsoft Research describes an experimental time-traveling debugger inside the next-generation Microsoft Edge web browser. The system allows a developer to move the execution state of a debugged web page backwards and forwards in time. With fine-grained knowledge of how a page's state evolves, developers can dramatically reduce the effort needed to find and diagnose bugs. 

Mark Marron and James Mickens introduce a new technique called interrogative virtualization that efficiently captures high-level application semantics, minimizing the size of the VM snapshots and event logs that the debugger uses to travel through time. Mark and James also describe how to leverage the browser's preexisting garbage collection infrastructure to further optimize the snapshot process. The result is a time travelling debugger which imposes negligible overheads at recording time, and which is fast enough at replay time to support interactive time-travel debugging.

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      md70

      Hi,

      Great stuff! Are there plans to make this available to the public?

      On a more technical note, when you're replaying the recorded action, is it safe to execute every action, including side effecting (and potentially not idempotent) functions?

      Regards

    • User profile image
      marron

      @md70: Hi and thanks for the questions. We are working with some great people on the product teams to figure out how to turn the experimental system into something that we can make public but, at this point, we don't have a concrete timeline for when this could happen.

      On the technical question, you are right to observe that we don't want to re-execute some calls that have side-effects. For example resending an XHR request which may be unexpected at the server. To handle this we do two things. First is that during the original execution we remember the result of these side-effecting operations. In the case of XHR what the responseText, responseType, etc. values are. Then when we replay the program and reach the send call we transform it into a nop (i.e., we don't actually send the request). Later when the program reads, say the responseText property, we return the value that was recorded in the original program execution.

    • User profile image
      Hannes​Kochniss

      So this is what we got out of mugshot.js. I saw the Video back at Mix 11 from James, and this along with the Siloing talk was (to me) the most exiting stuff of the conference, because it was promising something HUGE for testing/software development scaling, esp. in a legacy system, where this non-softwaredesign dependent way of record/replay for complex test runs, completely isolated from the "inner" complexity of the software, just dependent on the limited API of the browser, pays of once a certain Software complexity is reached.  This + Opensource = win for everybody. But I guess this is not going to happen on your side, as it's MSR territory, like your PEX-driving constraint resolver. .. some things will probably never change.

      I have my theories around this concept, I think you are up to something much bigger that just "historical debugging" suggests. I think that this record/replay could spawn a new way of testing that we don't have a name for, yet. In a way it's the jang to the Unittest jin, a dual principal, the domain would be in-memory testing. And what you call "nondeterministic behavior" I would call "out-of-process communication" (in the case of the browser "out-of-mainthread communication"" or "access to mutable global state out of programmers reach". As far as I can tell, this is the same principal.

      Back in the days, you mentioned the problem of latency replay in the mugshot.js paper, and needing a proxy/external tool to fix this. Isn't that something that serviceworkers could fix in the future?

    • User profile image
      paul

      this seems like *again* MS is headed for a bloated heap of none-functional-browser.

      please guys, can you just walk before you try and run... better yet, crawl before you try and walk! you have soooooo much work to do to produce a browser that works properly and doesn't render pages that look like a drunk five y/o with a crayon drew the page

      as a developer with 25 years experience (on Windows with VS) myself i understand the issues you've faced over the years and relate to the uphill struggle you have to get respect in the browser space...

      ... having said that you are just dooming yourselves right now by trying to bite of more than you can chew. think modestly and just try to do the basics.... the ie team has caused so much damage for the MS brand i don't want to see it continue into the future!

      all the best

    • User profile image
      androidi

      @paul: And what's the issue with using "report website problems" now that such is available in IE (OK I think I know the answer: bunch of internal/secure sites are not working anymore or sending stuff is prohibited/white lists etc)

    • User profile image
      ray

      er, this is not a new idea - although it is new to the browser.

      It's already available for Java (see Chronon time travelling debugger) as well as C/C++ (rr from mozilla and undodb).

      Finally, it would be ideal if the enabling technology for this was exposed as an API on top of the JS VM rather than as a tool that's only available to MS engineers.

    • User profile image
      ivane1

      Well, that's neat! Waiting for public release.

    • User profile image
      TheBitBender

      please make this available in VS for c# :)

    • User profile image
      marron

      @ray: you are correct that time-travel debugging has a long history of previous work. In a paper we published last year we review work on the topic going as far back as 1988. A major challenge in using previously described systems is the large performance impacts they can have, frequently in the range of a 2x-10x slowdown, which makes them impractical to use on a day-to-day basis. The major advance we made is lowering the overhead of running a program in time-travel mode to the point where it is negligible from a developers perspective. As described in the video, and in the paper I linked, we are able to fundamentally reduce the overhead costs by working at a higher level in the system (JS/HTML application vs. entire C++/Browser/OS stack) and leveraging existing features in the managed JS/HTML runtime (type-safety and GC).

      Your point about providing an API for the enabling technologies is an excellent one. As James mentions in the video we are excited about the possibilities of this new interrogative layer of virtualization and, hopefully, we will have more to say about this soon.

       

    • User profile image
      Colin

      This sounds similar to Visual Studio Ultimate edition's Intellitrace feature... correct me if I'm wrong

      @TheBitBender: If I'm right, it's already there for C#~

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.