public inbox for
 help / color / mirror / Atom feed
From: Mark Wielaard <>
To: frysk <>
Cc: Roland McGrath <>
Subject: Re: Reset breakpoints on fork (vfork followup)
Date: Tue, 29 Apr 2008 18:25:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On Tue, 2008-04-22 at 18:52 +0200, Mark Wielaard wrote:
> Roland, I CCed you in the hope that you could maybe point out some nice
> way now or in the future to do this. The patch itself might not be very
> interesting to you. The way we model Tasks and events means we do this
> in three stages. First we get a fork event and capture all the
> (software) breakpoint addresses, then we already create the Proc and
> then the main Task based on the pid given in the event, then we wait for
> an (stopped) event on this now Task, then we go over all the breakpoints
> left and patch in the original instructions again.
> This of course isn't very efficient since I assume the kernel could help
> us out here since it know the pages we touched through ptrace poke to
> set the breakpoints in the first place. If there was some way to have an
> event from the kernel where we got the forking and forked tasks in a
> quiescent state (at the same time) and then could inspect both and tell
> the kernel whether or not to copy the modified or original code pages
> that would be much better. Bonus points for having advanced knowledge of
> a pending exec event, which would wipe away any changes we do anyway
> (although I don't see how this would be possible).

A small followup without code, but hopefully enough information for
someone to design the right setup to make it happen. There is also still
the outstanding issue of frysk not handling vfork.

Getting events for vfork is not hard. In Ptrace.cxx we should also
request PTRACE_O_TRACEVFORK and in Wait.cxx we should handle the
PTRACE_EVENT_VFORK. This however does not bring us full vfork support.
vfork() is a special kind of fork() that blocks the parent till the
child process it just vforked calls exec(), the child process is not
allowed to do much (see the vfork manual page) but between the vfork
call and the exec call the child does share its memory pages with its
parent. This makes our current approach to handling fork() not work for
vfork(). If we alter any breakpoints in this new child before it calls
exec() it will alter the parent's memory pages also. So if we alter any
(software) breakpoints we need to track the state changes in the parent
(which will be blocked itself). Luckily the kernel can give us some
events to help with this all. In Ptrace.cxx we must request
PTRACE_O_TRACEVFORKDONE and in Wait.cxx we must also handle
PTRACE_EVENT_VFORK_DONE. Then we must put both child and parent into new
states and track any breakpoint manipulation.

I don't immediately see a clean way to handle fork and vfork the same
way even though they are so similar to the user. It would be nice to
have a way to express the TaskObserver.Forked in a way that the user of
such an observer doesn't have to care about what kind of fork it is
about. And to have it in such a way that the user of the observer can
easily inspect/manipulate both parent and child. Currently it must
handle two different events for parent and child, but it cannot assume
that either the parent or the child is in a state which allows any

I did make a little change to the current vfork test to have the right
counts (but didn't resolve it since the code isn't there yet, I tested
it by doing the above changes to Wait.cxx and Ptrace.cxx and pretending
the vfork is just another fork, but obviously it breaks when also doing
breakpoint Code observers at the same time).

2008-04-28  Mark Wielaard  <>

        * (testTaskVforkObserver): 
        Correct counts.



Test patch:

diff --git a/frysk-core/frysk/proc/ b/frysk-core/frys
index 5990546..ada14bd 100644
--- a/frysk-core/frysk/proc/
+++ b/frysk-core/frysk/proc/
@@ -89,10 +89,10 @@ public class TestTaskForkedObserver extends TestLib {
        assertEquals("number of child processes created",
                     1, forkObserver.forkCount);
-       assertEquals("number of child processes destroyed",
-                    1, forkObserver.terminatedCount);
-       assertEquals("number of times fork observer added",
-                    2, forkObserver.addedCount());
+       assertEquals("number of exits (includes initial process)",
+                    2, forkObserver.terminatedCount);
+       assertEquals("number of times fork+terminated observer added",
+                    2 + 2, forkObserver.addedCount());
     private void runForkTest(ForkObserver forkObserver, String[] argv) {

Not-committed-and-wrong! fvork handling patch:

diff --git a/frysk-sys/frysk/sys/cni/Wait.cxx b/frysk-sys/frysk/sys/cni/Wait.cxx
index f902bb0..ce267d5 100644
--- a/frysk-sys/frysk/sys/cni/Wait.cxx
+++ b/frysk-sys/frysk/sys/cni/Wait.cxx
@@ -102,6 +102,9 @@ logWait(frysk::rsl::Log* logger, pid_t pid, int status, int 
       case PTRACE_EVENT_FORK:
        wif_name = "WIFSTOPPED/FORK";
+       wif_name = "WIFSTOPPED/VFORK";
+       break;
       case PTRACE_EVENT_EXIT:
        wif_name = "WIFSTOPPED/EXIT";
@@ -168,6 +171,7 @@ processStatus(frysk::sys::ProcessIdentifier* pid, int status
       try {
        // The event message contains the process-ID of the new
        // process.
diff --git a/frysk-sys/frysk/sys/ptrace/cni/Ptrace.cxx b/frysk-sys/frysk/sys/ptr
index 4aa12eb..5fa1654 100644
--- a/frysk-sys/frysk/sys/ptrace/cni/Ptrace.cxx
+++ b/frysk-sys/frysk/sys/ptrace/cni/Ptrace.cxx
@@ -137,7 +137,7 @@ frysk::sys::ptrace::Ptrace::optionTraceClone() {
 frysk::sys::ptrace::Ptrace::optionTraceFork() {
 frysk::sys::ptrace::Ptrace::optionTraceExit() {

  reply	other threads:[~2008-04-28 11:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-25 17:52 Reset breakpoints on fork Mark Wielaard
2008-04-29 18:25 ` Mark Wielaard [this message]
2008-05-01 22:49 ` Roland McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).