Re: [bug-gawk] gawk child processes appear to be ignoring SIGPIPE

[Aharon Robbins]

Hi Andy and Daryl,

> On Thu, 24 Apr 2014, Andrew J. Schorr wrote:
> > When dealing with small files, it does not matter that gawk closes the
> > file early, because gzip was able to dump the output into the kernel buffers
> > without blocking on write.  With a large file like perlapi.1.gz, the gzip
> > process blocks on write.
> >
> > In gawk 4.1.0, the zcat (gzip) child process is killed by SIGPIPE, so it
> > goes away quietly.
> >
> > In gawk 4.1.1, a patch was added to ignore SIGPIPE.  This appears to be
> > inherited by the gzip child process, so it is not killed by SIGPIPE.  
> > Instead,
> > it gets an EPIPE write error that causes it to complain before exiting.

I agree that this diagnosis is correct.

> > I see the same problem in the master branch currently.  The attached
> > patch seems to fix it,

I think your patch is the correct one. I will try to apply it today.
If I don't get to it, feel free to apply it in gawk-4.1-stable and
merge to master.

> > although I'm confused about one point.  The
> > linux man page on my system for execve says:
> >   "*  The dispositions of any signals that are being caught are  reset  to
> >       the default (signal(7))."
> > Is this correct?  If so, I imagine that execl should also do this.
> > So I'm not sure why we need to do this explicitly.  Or does "being caught"
> > exclude the case where it is being ignored?

Right - being ignored is NOT the same as being caught. Ignored signals stay
that way across fork and exec.

Daryl:
> I'm no expert on programming C but I don't see how the signals with 
> handlers could *not* be reset to default since the original program is 
> replaced. Any signal handlers it had set up are no longer available.

Right. That's why they're reset.

> It does make some sense that signals being ignored could be carried to the 
> new program but that certainly is worrisome to me as a coder. I must
> make the assumption that signals might be ignored in my program depending 
> on what the calling program ha done. I'd have to use sigprocmask(2) to 
> ensure that signals I normally assume are fatal haven't been ignored.

That is exactly true.  Most people don't worry about it, because most
programs are run from the shell, but in principle one should do exactly
as you've stated.

Daryl, thanks for reporting this issue.

Andy, a huge thank you for root-causing it and supplying the patch.

Arnold