handling stack growth induced by the debugger

Robert O'Callahan robert at ocallahan.org
Wed Mar 18 01:38:55 UTC 2015


Jeff Muizelaar uncovered https://github.com/mozilla/rr/issues/1435, where
we fail to handle watchpoints placed in an area where we have unexpected
stack growth. I've fixed that and it wasn't hard to fix, but it exposes a
larger issue: memory reads performed for gdb can trigger automatic stack
growth beyond what happened during recording, in a way that causes
divergence. For example I have a test case that mmaps anonymous pages just
below the current stack pointer, then triggers a stack overflow. During
replay (or in gdb without rr at all), if you read from memory below the
stack pointer before the mmap happens, the stack grows automatically, the
explicit mmap splits the stack VMA into two pieces, and the stack overflow
does not occur because all necessary pages have been mapped.

This might not be a problem in practice, but it worries me because when you
combine watchpoints with reverse execution you end up doing watchpoints and
reads in all kinds of strange locations, which could trigger automatic
stack growth and lead to divergence if the original run had a SIGSEGV.

My current best idea is to allow spurious grow-downs during replay, but
record the faulting address for SIGSEGVs and when we replay a deterministic
SIGSEGV, if the faulting address is in (or just below) a growdown VMA,
completely unmap the growdown mapping since it must be spurious.

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/20ae31b2/attachment.html>


More information about the rr-dev mailing list