FF replay problem involving madvise

Chris Jones jones.chris.g at gmail.com
Wed Feb 20 00:42:06 PST 2013

On Tue, Feb 19, 2013 at 3:47 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> Currently rr maps per-thread scratch buffers in the recording process but
> not in the replay process. This helps us catch cases where the process
> reads or writes from the scratch buffer outside of a system call (which it
> should never do).

But that's a "legal" behavior of application code, right?  It's
unfortunate that buggy applications can corrupt the recorder state, but I
guess the risk of that was evaluated against the perf improvement and perf
won?  That would be reasonable.

I have an rr patch that fixes this by forcing madvise() to fail if it
> probes a scratch buffer during recording. However, there are other cases
> this wouldn't handle, such as if the process probes memory by just reading
> it and catching any SEGV signals. Another approach would be to map scratch
> buffers in the replay process, but then divergence due to scratch buffer
> access could be harder to detect. On the other hand, the syscall-wrapper
> module allocates its own scratch buffer which has similar kinds of issues,
> and that allocation happens in replay as well as recording, so maybe
> mapping all scratch buffers during replay isn't a big deal. I haven't got
> any other ideas.
> Anyone got any preferences?

I prefer to map the buffers during replay.  If the recorder can affect
application behavior in these kinds of ways, we should replay those effects


> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
> _______________________________________________
> rr-dev mailing list
> rr-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rr-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20130220/59e26673/attachment.html>

More information about the rr-dev mailing list