dmake 3.7 bug: loses child on 3b1

[Brian R. Haug]

In article <1362 at kosman.UUCP> kevin at kosman.UUCP (Kevin O'Gorman) writes:
>I snarfed dmake 3.7 by ftp, and I'm working to install it on my 3b1.
>The bootstrap make seemed to go fine.  The resulting object seems
>normal.  I did minimal edits: just to startup.h.  I did 'make sysvr3'.
>
>I installed the result.
>
>Now I'm trying to use dmake to make itself again: the acid test.
>
>It goes okay for several modules, and then at a certain point, it
>reports "Error -- lost a child" and dies.  If I repeat the command,
>
>The natural questions arise: has anyone seen this before?  Has anyone
>had success on a 3b1?  Does anyone have any hints?  Does anyone have
>any idea what the message means? (I've tried grepping the source,
>but don't see that message anywhere).

I saw this behavior as well.  After some examination and code modifications
I found out that the wait call was failing with the error that there were
no children.  Additional debug code showed the process number of forked
children and the value returned by wait.  When the error occurred, there had
been no waits for the child in question.  I used adb to set a breakpoint at
wait, and found that it was being called from getcwd(3c).  It seems that
many systems implement this subroutine as a call to popen(3C) followed by some
sort of read and then a pclose(3c).  Pclose has to do a wait, which may get
the child that dmake will later be searching for.

As best I can tell, this can not be easily fixed in any System V release (until
V.4 when we get waitpid) unless you re-write the getcwd function, or the dmake
function which calls getcwd.  Best of luck.