FF replay problem involving madvise

Thomas Anderegg thomas at tanderegg.com
Wed Feb 20 00:57:56 PST 2013


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


More information about the rr-dev mailing list