This is the mail archive of the mailing list for the frysk project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reset breakpoints on fork (vfork followup)


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() {

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]