FF replay problem involving madvise

Thomas Anderegg thomas at tanderegg.com
Wed Feb 20 00:31:13 PST 2013


If we map the scratch memory in the replay, we would at least have to
mprotect it, or similar. Otherwise, we wouldn't be able to catch accesses
the scratch memory, which should not happen (I think we talked about this
some other time already).

Concerning the other case you described with probing the memory: Isn't this
a case that is not really supported by rr regardless of mapping the scratch
memory in the replay? It would be a deviation to the untraced execution
either way.

Thomas

On Wed, Feb 20, 2013 at 12:47 AM, 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). This causes problems for some FF runs, because FF has
> code that uses madvise() to probe for a region of address space which is
> unmapped (we use pointers to this unmapped region instead of null pointers
> in some cases, for security reasons). If FF happens to probe a scratch
> buffer, madvise() will succeed during recording and fail during replay,
> causing divergence.
>
> 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?
>
> 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/fa18de17/attachment.html>


More information about the rr-dev mailing list