Emulating MAP_GROWSDOWN

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


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.

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


More information about the rr-dev mailing list