SIGCHLD race condition?

[mouring at etoh.eviladmin.org]

On Wed, 3 Oct 2001, Nicolas Williams wrote:

> On Wed, Oct 03, 2001 at 01:47:59PM -0500, mouring at etoh.eviladmin.org wrote:
> > On Wed, 3 Oct 2001, Nicolas Williams wrote:
> > > It's a neat trick. SIGCHLD arrives and the handler reaps the child and
> > > writes a byte to this place holder pipe, then, when the select() loop is
> > > entered you come out because there's that byte in the pipe, you check
> > > the child terminated variable and you exit. No more race condition.
> > >
> >
> > Neat trick, but I've seen scp terminate with a SIGCHLD before the pipe was
> > empty.
>
> There's no such pipe in the code now. It'd be merely a place holder to
> tie the SIGCHLD/wait() event to select().
>
> SSHD would still only exit IFF (child is dead && child fildes are dead).
>
> The pipe trick is merely a race avoidance technique.
>
> > I guess I'd have to see the code since I get a feeling we could lose data
> > on non-interactive session with this trick.  I'd rather track down what C
> > code is holding the offending file descriptor past's the due date and
> > rework the code.  I'm not too much a fan of repeating the last 'scp
> > missing data' thread.
>
> Wrong thread, methinks. This is the sigchld-arrived-before-entering-
> select()-but-after-checking-child_terminated-and-client-has-nothing-
> to-send-and-the-child's-fildes-are-closed-therefore-sshd-ends-up-
> waiting-forever-in-select()-for-the-client-to-send-something thread.
>

It is related..  The other thread is
sigchld-arrived-before-select-not-all-file-descriptors-are-closed-select-
hangs-until-either-a-bit-of-data-appears (IE sleep 30&exit)
or-hangs-forever (IE vi file, ctrl-Z, ctrl-d).

It is the same bug in reality.

- Ben