Closed
Bug 738965
Opened 13 years ago
Closed 6 years ago
Going back in time with the debugger
Categories
(DevTools :: Debugger, defect, P4)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: bruant.d, Unassigned)
References
(Depends on 1 open bug)
Details
(Whiteboard: [time-travel])
Use case:
1) Set 2 breakpoints in JavaScript code, run until the first one
2) press a "record" button and restart
Code runs until the second breakpoint and saves the states of the program
3) when reaching the second breakpoint, a UI appears and allows to inspect the program at any point in time between the 2 breakpoints.
Reporter | ||
Comment 1•13 years ago
|
||
In December, I wanted to work on that as a side project.
I once popped up on jsapi to mention that and had 2 calls with jorendorff and jimb (in CC) to discuss limitations of the new Debugger API.
What needs to be recorded:
1) Changes to objects properties
=> I initially planned to content objects by proxies to capture this information. Given some compartment and probably some performance issue, jimb&jorendorff suggested to rather use a watchpoint API. See bug 638044 and bug 638053.
2) Changes in function scopes
This could be done in 2 different ways:
* an "onset" event when a variable gets a new value
* snapshots of variable values generated (hopefully lazily) by the JS engine.
3) An idea mentionned by jimb was to design an API that different components could implement. When necessary, the debugger could ask this component to get back to an earlier state.
Such an API would have the advantage of distributing the work and also to put the responsibility of "get back in a past state" to each component.
Comment 2•13 years ago
|
||
This could be an interesting experiment.
I could see this requiring very large hunks of memory to store all the stack frames and be somewhat unpredictable in some cases. You'd want to isolate the browser from responding to additional events (which we do anyway) during a replay phase. I guess if you could alter some of the entry conditions (i.e., change state on some objects before beginning the replay) you could see how a particular section of code responds with different entry conditions, but without some fairly rich tools to edit and modify those objects, that type of setup maybe more painful than simply rerunning the code under breakpoint control.
Comment 3•13 years ago
|
||
This sounds like the reverse debugging that GDB has and seems useful. I would enjoy being able to do a step-into-PREVIOUS-function at a breakpoint.
There are a couple of videos online of how something similar works in Flash Builder.
(In reply to Rob Campbell [:rc] (:robcee) from comment #2)
> I could see this requiring very large hunks of memory to store all the stack
> frames and be somewhat unpredictable in some cases.
Maybe there's a way to "cheat", like save only the minimum information that is required to bring back state, or not save a thing and re-execute the script every time till the previous breakpoint? Of course the later would have issues with randomness.
Reporter | ||
Comment 4•13 years ago
|
||
(In reply to Dionysios G. Synodinos from comment #3)
> (In reply to Rob Campbell [:rc] (:robcee) from comment #2)
> > I could see this requiring very large hunks of memory to store all the stack
> > frames and be somewhat unpredictable in some cases.
>
> Maybe there's a way to "cheat", like save only the minimum information that
> is required to bring back state, or not save a thing and re-execute the
> script every time till the previous breakpoint?
Interesting. Just save the state of the first breakpoint and restart the program in order not to have to store too much information. It's not cheating, it's taking advantage of the classic time/space tradeoff :-)
> Of course the later would have issues with randomness.
I'm confident all sources of non-determinism (Math.random, date.now, event timestamps...) can be fully tracked and reinstated when necessary. It would take memory, but combined with what you described above, it sounds it could be largely reasonable.
Updated•13 years ago
|
Priority: -- → P4
Whiteboard: [time-travel]
Reporter | ||
Updated•13 years ago
|
Depends on: dbg-watchpoints
Comment 5•12 years ago
|
||
Have a look at Timelapse: http://www.cs.washington.edu/homes/burg/projects/timelapse/
Updated•10 years ago
|
Summary: Debugger able to go back in time → Going back in time with the debugger
Updated•6 years ago
|
Product: Firefox → DevTools
Comment 6•6 years ago
|
||
Closing as webreplay has surpassed this.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•