Re: [Fwd: Re: execv bug???]
Re: [Fwd: Re: execv bug???]
- Subject: Re: [Fwd: Re: execv bug???]
- From: Terry Lambert <email@hidden>
- Date: Tue, 29 Jan 2008 00:03:31 -0800
On Jan 27, 2008, at 11:56 AM, Peter Seebach wrote:
In message <email@hidden>, Steve writes:
So, are you suggesting then it could well be a bug with Leopard (it
works fine on Tiger and, it works fine as coded by simply removing
the
v from vfork)? Obviously, the simple solution on Leopard for now is
to
use fork. I shall proceed to make a small test program and submit to
Apple then.
I wouldn't consider it a significant bug; vfork is deprecated,
having been
a performance hack to improve performance on the VAX. The existence
of
modern systems with copy-on-write semantics makes it a waste of time
to try
to make things work with vfork; further, I wouldn't necessarily
expect either
process to be stable after calling vfork and then doing anything
other than
exec* and exit -- there's nothing I know of stating that chdir() calls
can't have side-effects that include modification of the caller's
address
space in some way, and you should never call anything that modifies
the
caller's address space from the child side of a vfork.
See the vfork man page:
[EINVAL] A system call other than _exit() or execve()
(or libc
functions that make no system calls other
than those)
is called following calling a vfork() call.
chdir() is a syscall. It is an error to call chdir() inside the
child of a
vfork.
Peter is 100% correct here.
When you vfork(), you "borrow" the parent process Mach task, Mach
thread, and BSD uthread, creating your own BSD process structure.
Any system call subsequent to a vfork() and prior to an execve() or
_exit(), and which operates on anything other than the BSD process
structure, will modify the state of the parent process, rather than
that of the child process. If you are lucky, then the child process
inherits the changed values from the parent process, and if you are
very, very lucky, the parent process doesn't mind this twiddling
happening.
Many OSs will in fact error out all system calls, other than execve()
and _exit() subsequent to a vfork(), and are correct to do so;
however, POSIX states that the behaviour is "undefined", and permits
the return of an EINVAL error - but does not require it. I made a
number of egregious system calls return EINVAL (those that would
modify credential and process group information), but didn't disable
everything, since it would have strongly damaged binary compatibiliy.
Instead, it's "deprecated", which means you should not depend on it
for newly compiled code.
You pretty much have three choices here:
(1) Save the current directory before the vfork(), change the current
directory of the main process to the one you want the child to have,
call vfork(), and when the parent gets back from the call, put the
parents directory back to what it was
(2) Switch to using fork() instead
(3) Switch to using posix_spawn()
Plan your code as if you expect vfork() to get more strict about the
calls that it allows between it and execve()/_exit(); even if nothing
changes in MacOS X, your code will be more portable.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden