Broken getppid() on Darwin/OSX

fuzzyping has asked for the wisdom of the Perl Monks concerning the following question:

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";
}
[download]

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
[download]

Thanks,

-fp

Comment on Broken getppid() on Darwin/OSX Select or Download Code

Replies are listed 'Best First'.
Re: Broken getppid() on Darwin/OSX by Eimi Metamorphoumai (Deacon) on Aug 01, 2004 at 20:09 UTC
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.	[reply]
Re^2: Broken getppid() on Darwin/OSX by fuzzyping (Chaplain) on Aug 01, 2004 at 20:12 UTC
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! -fp	[reply]
Re^3: Broken getppid() on Darwin/OSX by Eimi Metamorphoumai (Deacon) on Aug 02, 2004 at 13:08 UTC
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.)	[reply]
Re: Broken getppid() on Darwin/OSX by Zaxo (Archbishop) on Aug 01, 2004 at 20:14 UTC
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. After Compline, Zaxo	[reply]
Re: Broken getppid() on Darwin/OSX by superfrink (Curate) on Aug 01, 2004 at 21:20 UTC
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.	[reply]


There's more than one way to do things
	PerlMonks