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...
More information about the rr-dev