FF replay problem involving madvise

Robert O'Callahan robert at ocallahan.org
Tue Feb 19 15:47:23 PST 2013


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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20130220/3cb2d000/attachment.html>


More information about the rr-dev mailing list