Broken getppid() on Darwin/OSX

[fuzzyping]

I was testing out pid generation behavior on Mac OS X (10.3.4) when I noticed that the child process of a fork() was returning the parent process' parent id (1) instead of its own parent process id. This system is running Perl v.5.8.1RC3 for Darwin.

The behavior happens anywhere from 20-99% of the time, as you can see from the test output below. I was wondering if anyone else has experienced this behavior, I haven't been able to find anything on this via Google, the perldocs, etc.

The script:

#!/usr/bin/perl
use strict;

my $pid = fork();
die "Can't fork: $!" unless defined $pid;

if ($pid > 0) {
        print "I'm the parent and my pid is $$.  My child is $pid\n";
} else {
        print "I'm the child and my pid is $$.  My parent is " . getpp
+id() . "\n";
}

And the results:

$ while true; do perl fork.pl; sleep 1; done
I'm the parent and my pid is 2094.  My child is 2095
I'm the child and my pid is 2095.  My parent is 1
I'm the parent and my pid is 2097.  My child is 2098
I'm the child and my pid is 2098.  My parent is 1
I'm the parent and my pid is 2100.  My child is 2101
I'm the child and my pid is 2101.  My parent is 1
I'm the parent and my pid is 2103.  My child is 2104
I'm the child and my pid is 2104.  My parent is 2103
I'm the parent and my pid is 2106.  My child is 2107
I'm the child and my pid is 2107.  My parent is 1
^C

Thanks,

[Eimi Metamorphoumai]

Once a process dies, all of its children get owned by init (process id 1), so I think what you're seeing is that sometimes the parent gets to print out before the child (and then ends its life naturally) and the child moves to 1. And sometimes the child prints first, while the parent is still alive. If you were to add something like a sleep(10) to the parent to keep it alive, you'd probably see consistent results.

[fuzzyping]

Good catch, I think that was it. I guess I was surprised to see that happening on my 1.33 Ghz G4 Powerbook, while I don't see this happening on my dual-P3 1.4Ghz Linux server.

Thanks!

[Eimi Metamorphoumai]

After the fork you've got two different processes vying for the CPU, and which one gets it is undefined behaviour. So it looks like that version of Linux favours the child (I can see some sence in that, since often the child will exec something else anyway and block on IO, while the parent will simply wait for the child). And that version of MacOS doesn't seem to favour either, just throws them both at the scheduler and see what sticks.

As always with undefined behaviour, if your (not you personally) code depends on it, your code is wrong, even if it happens to work on your particular system on the particular day you tested it on. (For instance, under heavy load it might be entirely different.)

[Zaxo]

Where the child reports a ppid of 1, the launching parent has already exited. The init process, ppid == 1, has inherited the child.

(Added) In cases where the child does not get shunted to init, you may be leaving zombies. Run ps and look for processes in Z state. Call wait in the parent to solve both problems.

[superfrink]

I think you're seeing the results of a race where sometimes the parent dies before the child sees it's parent's PID. See http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC14 for info on why you see this on unix-like systems.