public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: frysk@sourceware.org
Subject: vfork thoughts
Date: Mon, 16 Jun 2008 13:14:00 -0000	[thread overview]
Message-ID: <48565AD5.8050902@redhat.com> (raw)

I've bee reading about vfork challenges for the past week. Here are my 
thoughts.

Mark when he fixed an issue related to breakpoints I think crystallized 
the issue with vfork in this thread:

http://article.gmane.org/gmane.comp.monitoring.frysk.general/1072

While at first the issue of breakpoints might seem to be nothing to do 
with vfork(), it is very relevant. Literature suggests that the use of 
vfork for any purpose other than an immediate prelude to an exec call is 
not advisable. However, there could - and probably are - examples of 
where this is not the case. Also as detailed in Mark's email this makes 
the usage of breakpoints troublesome, as child and parent share memory.

If we model vfork transparently though the fork observer then there is a 
danger of the user (be that an actual user, or an api call) assuming 
that the it is a true fork and not a vfork. Is it more sensible to model 
a completely separate set of observers to model vfork? This way, if 
there are breakpoints set in the child (and therefore the parent) we can 
uninstall them after the child execs. However this approach burdens the 
state machine with additional states that would essentially duplicate 
the fork states. Is the replication of code to deal with the vfork 
specific issues warranted here?

If anyone has a real life use case for debugging a vfork scenario we 
could model, that would help also.

Regards

Phil


             reply	other threads:[~2008-06-16 12:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-16 13:14 Phil Muldoon [this message]
2008-06-18 23:12 ` Andrew Cagney
2008-06-20 13:45 ` Tom Tromey

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=48565AD5.8050902@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=frysk@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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