handling stack growth induced by the debugger

Chris Jones jones.chris.g at gmail.com
Wed Mar 18 03:16:15 UTC 2015

On Tue, Mar 17, 2015 at 7:56 PM, Robert O'Callahan <robert at ocallahan.org>

> 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.

​A simple way to do that would be to checkpoint before reads or writes of
pages "near" but below where we think the stack break is.  Then throw away
the "experiment" after the operation.  If it's user-requested reads that
are causing spurious pages, then checkpointing is fast enough that users
won't notice the latency.​

​ But if not, yeah that's a pretty significant overhead.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20150317/a01eea37/attachment-0001.html>

More information about the rr-dev mailing list