Implementing reverse execution

Robert O'Callahan robert at ocallahan.org
Mon Feb 16 19:02:11 PST 2015


Reverse execution is basically implemented on master now, following the
design outlined in the previous email.

On Mon, Feb 2, 2015 at 6:38 PM, Robert O'Callahan <robert at ocallahan.org>
wrote:

> * The Timeline can maintain an internal database of which breakpoints get
> hit (or not) over various time intervals. This would speed up the above
> process a lot. This data could even be persisted alongside the trace data.
>

I haven't done this. I want to get some real-world experience to see
whether it matters.


> * Managing the checkpoint budget is interesting. It would be nice to
> encapsulate that in the Timeline, but clients could provide very helpful
> heuristics (e.g. checkpoint on new page load, or start of new mochitest).
>

Likewise. Currently we take a checkpoint (very) roughly every half-second,
and a winnowing algorithm throws out old checkpoints so that (again, very
roughly) the number of checkpoints retained is logarithmic in the elapsed
time.

I also optimized checkpointing so a checkpoint retains just one Linux task
per process, instead of per-thread, which allows rr to keep over 200
checkpoints of Firefox on my machine (limited by fds, not tasks, now).
Though the ReplayTimeline logic would currently never use anywhere near
that number.

There are currently some pathological cases where reverse execution won't
be efficient:
1) when a breakpoint/watchpoint is hit thousands of times between
checkpoints.
2) conditional breakpoints/watchpoints that get hit a lot.
These are fixable:
1a) if we hit too many breaks between checkpoint A and checkpoint B,
disable breaking, run forward to about halfway between A and B (say C),
reenable breaking and keep going from C to B. If no breaks are found
between C and B, refocus on A-to-C and retry. If breaks are found between C
and B, refocus on C-to-B and retry.
1b) Keeping information about breakpoint hits around persistently would
help speed things up.
2) Implement gdb's ConditionalBreakpoints protocol so that rr can evaluate
breakpoint conditions. (Only for condiitons that fit the condition
bytecode; conditional breakpoints that require user function calls can't
really be fast in the current architecture).

However, I want to get some experience debugging Gecko bugs using
reverse-exec before deciding what to do next. I'd appreciate anyone else's
feedback as well!

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20150217/a7ba3350/attachment.html>


More information about the rr-dev mailing list