52

Chrome sources debugging has buttons for step over, step into, and step out. There is no stepping backwards in time to see what were the previous functions.

HaoQi Li
  • 11,970
  • 14
  • 58
  • 77
  • 3
    There is no such concept in the [Chrome] debugger - this would be "non-trivial" to implement in a non-pure language: how would one "go backwards" over arbitrary side-effects? I don't know of *any* debuggers that support this feature. – user2246674 Jul 05 '13 at 23:47
  • 2
    Just bookkeeping everything is an option, just as Ollydbg debugger does for assembly. – HLL Feb 07 '15 at 23:05
  • 3
    Internet Explorer supports this – Sandy May 30 '16 at 06:59

6 Answers6

26

You can sort of go backwards if you click through in the "Call Stack" on the right side to see the parent functions.

HaoQi Li
  • 11,970
  • 14
  • 58
  • 77
  • There is also a setting in Chrome that let's you see an un-truncated call stack – Nate Anderson Dec 08 '17 at 14:04
  • 2
    Just to be clear, you are correct in saying you can only "sort of go backwards" using this approach-- while it allows you to move into callers and see the context that led you to the line the debugger is actually paused on, it isn't actually undoing any of the previous executions. – Alexander Nied Oct 01 '19 at 19:25
8

As I said on this answer, you can step back by placing a new breakpoint and restarting the actual function. Hope this makes the trick.

niutech
  • 28,923
  • 15
  • 96
  • 106
Charly.Org
  • 1,084
  • 10
  • 9
  • 1
    This is indeed correct, but instead of saying "restarting the actual function" which implies simply re-trying the whole debug session, you should have used the actual Chrome language "restart the current frame" – G. Stoynev Feb 15 '21 at 22:17
7

What I needed is in right side bar, right-click on an item in Call stack -> Restart frame. That restarts the selected function from the first line.

Sasha Davydenko
  • 794
  • 7
  • 12
2

One quick workaround I found out is to make a small change to the source file any change is fine (space, comment, whatever) while you are in the middle of the breakpoint then press Ctrl+s (save the file) and it will jump back to the first break point in that source. Then you can check your changes (F10 'step-in') then make another change if needed, Save it and it will restart. This is the fastest approach I have so far.

Harry S.
  • 141
  • 1
  • 2
0

This is what I was looking for and found this link first. It is a more advanced version of the question I suppose..

The correct keyword to help search this is "Time Travel Debugging"

First noted here in this version of nodejs called, "Node-ChakraCore".

https://github.com/nodejs/node-chakracore/blob/master/TTD-README.md

Master James
  • 1,691
  • 15
  • 19
  • 2
    "Time-travel debugging" is a different and more advanced concept from "reverse debugging" or "historical debugging". OP is asking about reverse debugging -- the ability to move backwards in the execution in a "step back" fashion. Time travel debugging also, additionally, allows users to edit the history if desired. See [reverse debugging](https://en.wikipedia.org/wiki/Debugger#Reverse_debugging) and [time travel debugging](https://en.wikipedia.org/wiki/Time_travel_debugging) for comparison. – dionyziz Oct 06 '18 at 06:31
0

replay.io

Disclaimer: my friend works at this company, and I learned about replay.io through him. He did not ask me to write this, I'm doing this of my own initiative because reverse debugging is awesome. I haven't tested it yet. I hope knowledge of such possibly closed source tools helps push the open source state of the art forward. They have some open source e.g. at: https://github.com/replayio/devtools but I don't know how exactly how much functionality that covers.

https://www.replay.io/ appears to have backwards/time travel debugging. It is presumably not fully FOSS but the website states that "Replay will always be free for individuals" so at least it is freemium.

The time travelling debug feature is documented at: https://docs.replay.io/debugging#d8966bc9bbb24a6f897c36ff70d398d1

replay.io appears to be trace-based: first you record one execution, and then you can replay the exact same thing as many times as you like, and go backwards in time if you want.

Once you have a trace, every execution is exactly the same, including e.g. the exact timing of asynchronous events such as getting HTTP responses back, so the recording presumably contains stuff like asynchronous events.

A common use case for this type of reverse debugger is to run your CI through it every time, so that you are able to reproduce bugs that depend on race conditions.

In the compiled languages world, the amazing open source Mozilla rr achieves some similar looking functionality.

One cool thing is that replay.io appears to be able to render DOM as it would render on the browser at each step even when going back.

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985