FF replay problem involving madvise
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rr-dev