vfork never ends

Question

The following code never ends. Why is that?

#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>
#define SIZE 5
int nums[SIZE] = {0, 1, 2, 3, 4};
int main()
{
  int i;
  pid_t pid;
  pid = vfork();
  if(pid == 0){  /* Child process */
    for(i = 0; i < SIZE; i++){
      nums[i] *= -i;
      printf(”CHILD: %d “, nums[i]);    /* LINE X */
    }
  }
  else if (pid > 0){  /* Parent process */
    wait(NULL);
    for(i = 0; i < SIZE; i++)
      printf(”PARENT: %d “, nums[i]);   /* LINE Y */
  }
  return 0;
}

Update:

This code is just to illustrate some of the confusions I have regarding to vfork(). It seems like when I use vfork(), the child process doesn't copy the address space of the parent. Instead, it shares the address space. In that case, I would expect the nums array get updated by both of the processes, my question is in what order? How the OS synchronizes between the two?

As for why the code never ends, it is probably because I don't have any _exit() or exec() statement explicitly for exit. Am I right?

UPDATE2:
I just read: 56. Difference between the fork() and vfork() system call? and I think this article helps me with my first confusion.

The child process from vfork() system call executes in the parent’s address space (this can overwrite the parent’s data and stack ) which suspends the parent process until the child process exits.

I think I tend to agree with the Linux man page on vfork: "It is rather unfortunate that Linux revived this spectre from the past". Given that fork is (in any version of Linux you're likely to be using) a lightweight operation, I'd stop worrying about what vfork might or might not do. — Philip Kendall
There's one error in your assumptions. "Instead, it shares the address space." This is not correct. It can share the address space, but it doesn't have to. Some operating systems only implement the vfork semantics of suspending the parent but still do a copy of the address space like normal fork. The reason for that is that there were many bugs caused by sharing the address space (I seem to remember execvp on some system calling malloc and leaking memory in the parent). — Art
@Art gives an reference if you think "Instead, it shares the address space." is not correct.. I like to read more :) In my knowledge vfork(), creates new process that shares the same address as calling process — Grijesh Chauhan
@GrijeshChauhan Read openbsd.org/cgi-bin/cvsweb/src/sys/kern/… function sys_vfork. If it was sharing the address space the call to fork1 would have the flag FORK_SHAREVM, it doesn't. I know that other operating systems made the same choice, can't recall which ones at this moment. Last time I researched this was 10 years ago. — Art

Philip Kendall Philip Kendall · Accepted Answer · 2013-01-23T12:50:18

To quote from the vfork(2) man page:

The vfork() function has the same effect as fork(), except that the behaviour is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit() or one of the exec family of functions.

You're doing a whole bunch of those things, so you shouldn't expect it to work. I think the real question here is: why you're using vfork() rather than fork()?

vfork never ends

5 Answers