site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com See the vfork man page: Peter is 100% correct here. You pretty much have three choices here: (2) Switch to using fork() instead (3) Switch to using posix_spawn() -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Jan 27, 2008, at 11:56 AM, Peter Seebach wrote: In message <479CD1DB.4030504@yahoo.com>, 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. [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. 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. (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 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. This email sent to site_archiver@lists.apple.com