Shell out bug in pg (but a more general problem)
Andy Greener
andy at istbt.UUCP
Thu Feb 28 22:33:26 AEST 1985
We recently had an intermittent problem when using the "shell out" in
pg (Sys V.2 on Vax 750). Depending on the length of the preceding
pipeline (the problem only occurs when pg is the tail of a pipeline)
pg would resume without waiting for the child shell to complete -
result: two processes trying to read from the terminal.
On investigating in the pg source I found that it does a "wait(0)"
without testing the return pid (this "mechanism" is common in Sys V
code as far as I can tell). It is relying on the wait being interrupted
by the death-of-a-child signal when the sub-process terminates.
However, the Sys V shell makes the last process in a pipeline the parent
of all the others, so if the pipeline contains a few processes the
first may already have died, resulting in the wait(0) returning immediately
and pg carrying on its merry way.
It seems that this practice of relying on a signal to terminate the
wait is inherently dangerous, especially as the signal(2) man section
states in reference to SIGCLD and SIGPWR:
"Their use in new programs is strongly discouraged"
Does one hand at AT&T know what the other is doing? It is almost beyond
comprehension that such a major screw up has seen the light of day.
It undoubtedly will produce unforseen effects elsewhere (eg Sys V tar
forks mkdir, and uses the same wait mechanism - we had problems here too).
Do they do any testing of their "products"? My impression of
Sys V.2 is that it was rushed out the door; there are other problems
which we have come across that are really only of interest to other
Sys V sites. I won't bore you with the details here, but I will respond
to mailed requests and if there's lots of interest I'll post to the net.
Andy Greener Imperial Software Technology
London, ENGLAND.
{mcvax, qtlon, inset, root44}!ist!andy
"UNIX System V: from now on consider it sub-standard"
More information about the Comp.unix.wizards
mailing list