handling stack growth induced by the debugger

Robert O'Callahan robert at ocallahan.org
Wed Mar 18 02:56:40 UTC 2015


On Wed, Mar 18, 2015 at 3:21 PM, Chris Jones <jones.chris.g at gmail.com>
wrote:

> On Tue, Mar 17, 2015 at 6:38 PM, Robert O'Callahan <robert at ocallahan.org>
> wrote:
>
>> ​if you read from memory below the stack pointer before the mmap happens,
>> the stack grows automatically
>>
>
> ​I was going to suggest that maybe we should start tracking automatic
> stack growth/shrinkage by poking the page we thought was bottommost in the
> mapping and the first thought-unmapped page below it, but it sounds like
> that won't work.
>

Yeah, I haven't found a way to discover the actual size of the stack VMA
from outside the process, other than by parsing /proc/maps.


> I wonder if auto stack growth wouldn't happen if we used PTRACE_PEEKDATA
> instead of reading the memory fd?  Somewhat doubt it.
>

I haven't tried that, but even if it worked, it would be a pain.

I thought about disabling MAP_GROWDOWN during replay and then emulating
growdowns in the replaying process, only for actual tracee execution, by
handling unexpected SIGSEGVs --- but that would be a performance hit.

I thought about various schemes for trying to clean up spurious growdown
pages, perhaps after every mmap, but they all fail because I don't know how
to distinguish spurious growdowns (e.g. triggered by gdb reads) from
tracee-triggered growdowns.

So I'm sticking with the approach in my previous email.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20150318/f6f85750/attachment.html>


More information about the rr-dev mailing list