Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpfcso!hpfcdc!rml
From: rml@hpfcdc.HP.COM (Bob Lenk)
Newsgroups: comp.sys.hp
Subject: Re: About wait(2)...
Message-ID: <5570624@hpfcdc.HP.COM>
Date: 7 May 91 17:16:30 GMT
References: <281737c1.49d2@petunia.CalPoly.EDU>
Organization: HP Fort Collins, Co.
Lines: 69

> Then there is a line such as 
>   if (WIFEXITED(w)) return w.w_retcode;
> 
> This does not compile under HP/UX, with an "operands of cast have
> incompatible types" error.  The sys/wait.h file defines WIFEXITED using
> a cast of struct to int, as opposed to bsd which does not.
> 
> So I changed the above line to
>   if (WIFEXITED(w.w_status)) return w.w_retcode;
> which compiles ok.

This should work fine.  The HP-UX macros are compatible with POSIX rather
than BSD.  In newer versions of HP-UX, <sys/wait.h> has a BSD compatible
version of these macros within #ifdef _BSD.

> This same scenario exists 5 places in the package.  Now I am at a point
> were different parts of the packgage crash with a Bus Error at certain
> points in the code.  It doesn't crash in this code, but since this is
> the part I changed, I tend to suspect a problem here.  I suspect that
> if the code returns the wrong status here, it could provoke a crash
> elsewhere in the system.

I don't think there's any relationship.

> Furthermore, the daemon isn't cleaning up its zombies like it should.
> 
> There also are a couple of wait3() calls in the system, which I didn't
> make any changes to.
> 
> In the man page for wait(2), there is a line which says:
>   "The third parameter to wait3 is currently unused, and must always be
>   a null pointer".
> In one place this is not null in my code.

I believe wait3() will return an EINVAL error.  (That's what the manual
says.  I don't have a 6.5 system or source handy to check - but you
should be able to verify with a small program if you like).  This could
easily be causing the unreaped zombies.  It's possible that some code
isn't detecting the error, is expecting some returned values to have
useful data, and is causing the core dumps.

There is no supported way to get the functionality of the third
parameter to wait3().  In order to port this, you need to check how the
code uses the rusage structure.  You can get the same information as in
the CPU time fields (ru_utime and ru_stime) with times(2) (call it
before and after wait/wait3/waitpid - difference in child times is time
for newly reported child).  The information in the other rusage fields
is not available.

> My questions are these:
> 
> 1. Did I do something wrong in the changes I made?

Only in supplying the non-NULL third parameter to wait3().

> 2. Is there a difference in the way wait() works on HP/UX?

Only in (a) not supporting the third parameter to wait3() and
(b) difference from BSD on type of status argument and thus on type of
argument to the WIF*() macros.

> 3. What happens if the third parameter to wait3 isn't a null pointer?
See above (EINVAL error, I think).

		Bob Lenk
		rml@fc.hp.com
		{uunet,hplabs}!fc.hp.com!rml

Normal disclaimer - not an official response from HP.