Robert O'Callahan robert at ocallahan.org
Wed Dec 23 20:42:28 UTC 2015

On Wed, Dec 23, 2015 at 8:16 PM, Robert O'Callahan <robert at ocallahan.org>

> MAP_GROWSDOWN is a funky Linux feature that is usually applied to stack
> mappings. When the kernel detects a user-space access to unmapped memory,
> and the next mapping after the faulting address is MAP_GROWSDOWN, the
> kernel automatically extends the mapping downward so that the faulting
> address is valid and user-space can continue execution --- providing this
> does not cause the mapping to exceed the task's stack size limit.
> This causes problems for rr because it changes the memory map in a way
> that rr can't directly observe. It means that any read of task memory,
> including reads performed internally by rr (via /proc/<pid>/mem) or on
> behalf of gdb, can cause the memory map to change. This can potentially
> even cause observable side effects for programs that map or unmap memory
> areas overlapping the MAP_GROWSDOWN mapping. This is a problem when those
> reads happen during replay but not recording, leading to some subtle bugs.
> It also makes it difficult to maintain rr's cache of the current memory map.
> To avoid these issues, I'll try stripping the MAP_GROWSDOWN flag when we
> map segments and emulate the MAP_GROWSDOWN behavior in rr itself during
> recording. When a SIGSEGV on unmapped memory is detected, rr will try to
> extend the next mapping downward itself, and emit an event to the trace to
> indicate the mapping change. This will make all memory map changes explicit
> in the trace and avoid the problems mentioned above. There will be a
> performance penalty but I expect it to be small. I'll probably try to
> reduce the number of traps by growing segments by at least 64K at a time.

This is implemented now.

lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20151224/c351d9b2/attachment.html>

More information about the rr-dev mailing list