bash misbehavior

Pierre A. Humblet
Tue Sep 28 20:27:00 GMT 2004

Christopher Faylor wrote:
> On Mon, Sep 27, 2004 at 09:33:08PM -0400, Pierre A. Humblet wrote:
> >The following command produces an unexpected
> >result with standard Cygwin and bash
> >
> >~: echo 1 | `echo cat` &
> >[1] 180019
> >~: 1
> >Use "logout" to leave the shell.
> >[1]+  Done                    echo 1 | `echo cat`
> >
> >If ignoreeof is off, bash goes away.
> >
> >It looks like fhandler_termios::bg_check returns an error,
> >not sure what's going on. I have a trace available.
> Are you sure that bash is doing the right thing?  

Not sure, but it's doing on Cygwin what it is doing elsewhere.
So if it isn't right, there must be a Cygwin related explanation.
It is not pid reuse in this case.

> Strace implies that it
> is setting the process group of the terminal to a nonexistent pid.  It
> is a bug in cygwin that this is allowed but it seems like a bug in bash
> that it is doing this at all.

I don't see that it is required that a process with pid == "pgid" should
still exist at the time tcsetpgrp("pgid") is called, only that an existing
process (in the same session as the calling process) has pgid "pgid". 
The process making the tcsetpgrp call has that pgid, so it's OK.

Coincidentally I have a related issue on my to do list. It is required
that a pgid not be reused while any process has it as pgid. Cygwin
doesn't insure that and can suffer from pgid reuse. Because killing a
bash job involves killing all processes with matching pgid, innocent
processes can get killed.

The solution involves having setpgid inject a handle to the original
Win process into the destination of the setpgid. This is not so easy
to do from the parent, I don't see how it could close an existing
(now useless) handle in the child.
Also, bash has both the parent and the child set the pgid of the
child at about the same time. Thus we have to deal with a race condition.
We also want only one handle to get injected (or at least delete 
duplicate pgid handles before the next fork or exec).

> Fixing the bug in cygwin seems to cause bash to behave better but it
> still seems strange.  This seems like YA instance of bash assuming that
> it can rely on the fact that a recently exited pid will be invalid.

Yes, it's strange. See below.
> Anyway, thanks for the bug report with simple test case.  The fix is
> in CVS.

Your patch assumes that the pinfo of the pgid should still exist.
That's different than insuring that the Win process object is still around. 
I would #ifdef it out until we get a better grip on this. 

More information about the Cygwin-developers mailing list