On Wed, 10 Mar 1999 17:31:13 GMT 
 Richard Earnshaw <rearnsha@cambridge.arm.com> wrote:

 > >Synopsis:       Breakpoints lost under heavy swapping

 > >Description:
 > 	I've been trying to track down a bug which is causing random 
 > 	seg-faults on my shark when it is swapping heavily and noticed that
 > 	breakpoints set by gdb are not always being honoured.  It would appear
 > 	that a page that has a breakpoint set looses this if the page gets
 > 	swapped out.

Hm.

A page of text is backed by a vnode, and thus, the vnode pager.  So,
when a fault happens on a text page, the vnode pager pulls the page
from the backing vnode.  Simple enough; that's how it's always worked
in NetBSD :-)

When you set a breakpoint, you're modifying the page.  Since text pages
are read-only, we must map the page read-write, modify the page, and
set it back to read-only.

Since the text page may be shared, we must copy it before we modify it,
and turn it into an anonymous memory page, backed by swap.  Make sure
it's marked dirty so that it's cleaned to swap so that faulting it back
in will work.  This is just basic copy-on-write.

Here is my guess:

I suspect that somewhere along the line, in the new path that UVM takes
to do this sort of thing, the page is becoming reassociated with the
vnode from which it originally came, so that when the fault happens when
the process runs again, the text page is pulled from the vnode, thus
losing your breakpoint (and maybe `leaking' a page of swap, if the COW'd
text page was clened!)

Note that in UVM, we don't create a new VM object for the COW'd text
page (like we would have in Mach VM; COW was the main purpose of
object chains in Mach VM).  Instead, an `anon' entry is created for
the page... if an `anon' exists for a page, it is used.  If not, the
lookup just falls though to the original VM object.

Are we losing `anon' entries?

Chuck?  Insights on this?

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>