On 16/04/2014 12:14, Till Schneidereit wrote:
On Wed, Apr 16, 2014 at 1:52 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote:
On 2014-04-15, 7:14 PM, Gijs Kruitbosch wrote:
On 16/04/2014 00:05, Robert O'Callahan wrote:
We just released rr 1.2 and I think this would be a good time for
people to
try to use it for one of the tasks it was designed for: debugging
intermittent test failures.
This is awesome! Three questions:
1) Is anyone working on something similar that works for frontend code
(particularly, chrome JS)? I realize we have a JS debugger, but
sometimes activating the debugger at the wrong time makes the bug go
away, and then there's timing issues, and that the debugger doesn't stop
all the event loops and so stopping at a breakpoint sometimes still has
other code execute in the same context... AIUI your post, because the
replay will replay the same Firefox actions, firing up the JS debugger
is impossible because you can't make the process do anything.
I think you want to consult the spidermonkey hackers to see how feasible
that will be...
At the JS work week in Toronto in late March, we discussed this.
Unfortunately, that was one of the relatively few sessions for which no
protocol exists. :(
The gist of the results was that, sadly, this is incredibly hard to pull
off, if at all. Pretty much any JS program of meaningful size has complex
interactions with the DOM and the network. For those, we can't prove
whether it's possible to replay instructions without completely changing
the outcome. I guess if we were to implement a complete recording/replaying
shim of the DOM and network APIs, we could overcome this issue. It's
certainly a very different project from rr, though.
(Just for the record: I would *love* having this capability, and was very
disappointed when the conversation converged on this conclusion.)
Dumb question time: could you implement something that supported (a
subset of) the current remote debugging API based on an RR recording?
Obviously any actual state changes wouldn't work, but you would be able
to set breakpoints or read variable states at various times, and it'd be
a lot easier to use than gdb + lots of macros to read JS state. I guess
you might need to turn off some levels of the JIT when recording because
there's no debugger inspection support at all in some cases? :-(
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
