File descriptor number disagreement

Peter Naulls peter at
Tue Jun 14 03:27:41 PDT 2005

In message <42A736B6.70002 at>
          Nick Burrett <nick at> wrote:

> Peter Naulls wrote:
> > Whilst we're on the issue of redirection, there's some respawn thing in
> > Firefox (I don't know what the exact mechanism is) that occurs on an
> > upgrade, or initial run.  What ends up happening is that stderr/stdout
> > redirection isn't propogated, and they end up blatting the screen.  And
> > suggestions where I ought to be looking?
> Check that the execve function and in particular the use of the CLOEXEC 
> flag.  It might be that these file descriptors are being closed and not 
> propogated correctly to the child process.

The behaviour is at least understandable, if not always desirable.  The
following program demonstrates the problem if you use redirecton on

  #include <unistd.h>
  #include <stdio.h>
  int main(int argc, char *argv[]) {
    puts("test program");
    if (argv[1] && strcmp(argv[1], "1") == 0) {
      puts("second run");
    } else {
      char *args[] = { "1", NULL };
      puts("first run");
      execv("!RunImage", args);
    return 0;

Looking at at exec.c we see that all the file descriptors are closed if
there's no parent process:

  if (__proc->ppid == 1)
      /* This process doesn't have a parent. Technically, all file descriptors
         that don't have FD_CLOEXEC set should remain open, but if we are
         calling a non-UnixLib program then it won't know about them and so
         they will never get closed. */
      __free_process (__proc);

For the moment, in my build, I'm going to disable this.   This is
similar to a previous problem we discussed involving determining if
we're running a UnixLib binary or not.  Perhaps one (convoluted)
solution in this instance is to determine if output is redirected, and
then employ the RISC OS CLI redirection syntax - if this is possible in
this situation.

Peter Naulls - peter at        |
Unix Programs on RISC OS               |

More information about the gcc mailing list