On Wed, Apr 16, 2014 at 11:14 AM, Gijs Kruitbosch <[email protected]>wrote:
> 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. > Your understanding is correct. Implementing some kind of proper JS debugging on top of rr is technically feasible, and would actually be super awesome for our front-end contributors and also Web developers --- but it would be a lot of work. It's possible, but rather painful, to figure out what JS is doing using gdb. More and better gdb helper scripts would improve that situation. So rr isn't a great solution for JS developers at this time ... unless you're really desperate. Looking at browser-chrome, maybe we should be desperate :-). If you are desperate, try using rr to record and replay bugs that matter to you. If that works, it may be worth investing to make JS debugging through rr+gdb a bit more palatable. 2) Is anyone working on making this available on our TBPL infra for try > pushes? > Having a set of rr-enabled tests running on TBPL would be good but there are a few issues: -- Some bugs might not reproduce at all under rr. So it would be unwise to stop running our not-under-rr tests. -- The test slaves running rr would need to meet rr's specs and be bare-metal or VMs with perf counter virtualization enabled. -- We would need a story for debugging test failures recorded by rr in our test farm. "ssh into the box" is the easiest, technically. We haven't done any work to make traces portable and generally that's going to be either fragile or slow to replay. 3) Is support for other platforms than Linux/gdb (thinking Mac/lldb > particularly) planned? > Mac might be feasible but would be a massive amount of work. Other projects would be more valuable (e.g. x86-64, Android, improved debugging features). So, no. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
