vfork thoughts

vfork thoughts

[Phil Muldoon]

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

Re: vfork thoughts

[Andrew Cagney]

Phil Muldoon wrote:
> 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.
Totally agree.
>
> 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.

Perhaps look at the fork/daemon code.  It uses a vfork, followed by a 
fork, followed by an exec.  Stepping through that would be way cool!

>
> Regards
>
> Phil
>
>

Re: vfork thoughts

[Tom Tromey]

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

gcc uses vfork when spawning child processes.  And, the code that
actually does this does do some work between the vfork and the exec --
it is extremely common to move file descriptors around here.  So, if
you want to debug in this region, or just want to debug child
processes created by vfork, gcc works :).  There are probably a lot of
other examples like this.

Tom