FF replay problem involving madvise

Nimrod Partush nimrodpar at gmail.com
Wed Feb 20 08:38:39 PST 2013

I actually had code for replaying the scratch buffers at some point, I'll
try having a look for it. I remember however there was some problem
with itbut this could
be just that the mmaps table looks different, so thats not really a problem.


On Wed, Feb 20, 2013 at 10:57 AM, Thomas Anderegg <thomas at tanderegg.com>wrote:

> On Wed, Feb 20, 2013 at 9:42 AM, Chris Jones <jones.chris.g at gmail.com>wrote:
>> 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.
> Yes it is legal, but it (probably) would result in a segfault in the
> untraced execution, which we can then at least report in the replay.
> If the scratch memory is mapped in the replay as well, this segfault will
> go unnoticed if no further precautions are installed.
> So I'm not sure if the recorder behaviour should be exactly replayed.
> The scratch memory is used for correctness with blocking system calls: For
> example, if a thread issues a read syscall, rr schedules another thread
> while the read syscall is processed by the OS as this operation is blocking.
> The other thread could then access the memory location to which the read
> system call will write the data to, which could introduce data races that
> are not reproducible in the replay, hence the indirection with the scratch
> memory.
> Of course, another approach would be to just wait for the blocking system
> calls, but that will hurt performance, e.g. for reads on sockets with high
> latencies.
> _______________________________________________
> 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/4c00a601/attachment.html>

More information about the rr-dev mailing list