Date: Sat, 29 Sep 2001 23:28:39 +0100 From: David Taylor <davidt@yadt.co.uk> To: Alfred Perlstein <bright@mu.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Doubt of system(3) Message-ID: <20010929232839.A91153@gattaca.yadt.co.uk> In-Reply-To: <20010929170332.Y59854@elvis.mu.org>; from bright@mu.org on Sat, Sep 29, 2001 at 17:03:32 -0500 References: <200109291527.f8TFRrU76727.toshi@jp.FreeBSD.org> <20010929153433.U59854@elvis.mu.org> <20010929214338.A57903@gattaca.yadt.co.uk> <20010929221658.B57903@gattaca.yadt.co.uk> <20010929170332.Y59854@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 29 Sep 2001, Alfred Perlstein wrote: > * David Taylor <davidt@yadt.co.uk> [010929 16:17] wrote: > > On Sat, 29 Sep 2001, David Taylor wrote: > > >=20 > > > If you: > > >=20 > > > 1. Fork, and create a child (say, pid 10) > > > 2. Call system, which forks and creates a child (say, pid 11) > > > 3. Make the child (pid 10) exit now. > > > 3. Interrupt the call to _wait4(pid [=3D11], ...); > > >=20 > >=20 > > I've now managed to reproduce this... > >=20 > > Test program at http://www.yadt.demon.co.uk/system-bug.tar.gz > >=20 > > I'm pretty sure that's incorrect behaviour, and I also beleive the orig= inal > > patch posted to this list should fix it... >=20 > I should have realized that, especially since I just spent a week > trying to track down the same problem... >=20 > *smacks head* >=20 > The posted patch is ok, except for the fact that it returns successful > if an rfork thread has reaped the child, another variation is here, > which returns an error ECHILD if someone has reaped our spawed > child, and also keeps EFAULT propogation although that's not going > to happen because of the arguments being on the stack and NULL. >=20 > What do you think? Should we silently mask ECHILD? what if wait4() > returns a different error code in the future? Shouldn't we propogate > that? Well, system(3) claims system() will only return errors from invoking fork() or waitpid() [which, being pedantic, it doesnt actually invoke]... Errors from fork() are just passed straight through, so that's ok... As for wait4(), returning ECHILD from system() doesn't make much sense to m= e. We obviously _did_ have a child at some point, and if it went away before our wait4() call because someone else called wait4() or whatever, I don't think we should complain. If, somehow, EFAULT is returned, it should probably get propagated. However, on second thoughts, since system() is supposed to return the child's exit status, I'm not sure what to do with ECHILD other than just propagate it back to the program, since the exit status has already been given to some other program, and there's no way we can get it. So we either lie about the exit status and possibly break something that relies on that, or return a rather unexpected error. IMO, the below patch is probably the best solution. =20 > cvs diff: Diffing . > Index: system.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/lib/libc/stdlib/system.c,v > retrieving revision 1.7 > diff -u -r1.7 system.c > --- system.c 2001/01/24 13:00:59 1.7 > +++ system.c 2001/09/29 21:55:41 > @@ -53,7 +53,7 @@ > __system(command) > const char *command; > { > - pid_t pid; > + pid_t pid, savedpid; > int pstat; > struct sigaction ign, intact, quitact; > sigset_t newsigblock, oldsigblock; > @@ -86,8 +86,9 @@ > execl(_PATH_BSHELL, "sh", "-c", command, (char *)NULL); > _exit(127); > default: /* parent */ > + savedpid =3D pid; > do { > - pid =3D _wait4(pid, &pstat, 0, (struct rusage *)0); > + pid =3D _wait4(savedpid, &pstat, 0, (struct rusage *)0); > } while (pid =3D=3D -1 && errno =3D=3D EINTR); > break; > } >=20 --=20 David Taylor davidt@yadt.co.uk --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7tksXfIqKXSsJ/xERAtj4AJ0fIyOLlyU5zF2wOK2N/xnsM0NOwQCgxL/h Z7WwPSc7CtoEGg1VjZHAgKU= =JBQU -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010929232839.A91153>