title: waitpid - WIFEXITED returning 0 although child exited normally
body: <p>I have been writing a program that spawns a child process, and calls <code>waitpid</code> to wait for the termination of the child process. The code is below:</p>
  
  <pre><code>  // fork &amp; exec the child
    pid_t pid = fork();
    if (pid == -1)
      // here is error handling code that is **not** triggered
  
    if (!pid)
      {
        // binary_invocation is an array of the child process program and its arguments
        execv(args.binary_invocation[0], (char * const*)args.binary_invocation);
        // here is some error handling code that is **not** triggered
      }
    else
      {
        int status = 0;
        pid_t res = waitpid(pid, &amp;status, 0);
  
        // here I see pid_t being a positive integer &gt; 0
        // and status being 11, which means WIFEXITED(status) is 0.
        // this triggers a warning in my programs output.
      }
  </code></pre>
  
  <p>The manpage of <code>waitpid</code> states for <code>WIFEXITED</code>:</p>
  
  <pre><code>WIFEXITED(status)
      returns  true  if  the child terminated normally, that is, by calling exit(3) or
      _exit(2), or by returning from main().
  </code></pre>
  
  <p>Which I intepret to mean it should return an integer != 0 on success, which is not happening in the execution of my program, since I observe <code>WIFEXITED(status) == 0</code></p>
  
  <p>However, executing the same program from the command line results in <code>$? == 0</code>, and starting from gdb results in:</p>
  
  <pre><code>[Inferior 1 (process 31934) exited normally]
  </code></pre>
  
  <p>The program behaves normally, except for the triggered warning, which makes me think something else is going on here, that I am missing.</p>
  
  <p><strong>EDIT:</strong><br>
   as suggested below in the comments, I checked if the child is terminated via segfault, and indeed, <code>WIFSIGNALED(status)</code> returns 1, and <code>WTERMSIG(status)</code> returns 11, which is <code>SIGSEGV</code>.</p>
  
  <p>What I don't understand though, is why a call via execv would fail with a segfault while the same call via gdb, or a shell would succeed?</p>
  
  <p><strong>EDIT2:</strong><br>
  The behaviour of my application heavily depends on the behaviour of the child process, in particular on a file the child writes in a function declared <code>__attribute__ ((destructor))</code>. After the <code>waitpid</code> call returns, <strong>this file exists and is generated correctly</strong> which means the segfault occurs somewhere in another destructor, or somewhere outside of my control.</p>