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

[Andrew J. Schorr]

Hi Daryl,

On Wed, Apr 23, 2014 at 04:37:47PM -0500, Daryl F wrote:
> Attached is the same thing with gawk 4.1.0 using verbose=0
> environment variable since it doesn't add anything useful. It also
> didn't get rid of the chattiness either. Oh well.
> 
> I'm not saying that gawk is broken but that it's behaviour has
> changed between 4.1.0 and 4.1.1 and I thought it should be noted.

You are correct!  I'm sorry for taking so long to understand -- I was
comparing to a patched version of gawk 4.1.0 that included the patch
that is causing the broken pipe error message from gzip.

I should note that I think gawk 4.1.1 should give the correct results,
but I agree that the error message from gzip is annoying.

> Since you have not been able to reproduce the broken pipe with 4.1.1
> I'll assume it is something wrong on my end.

I have reproduced it.  Here is a simple example that I think demonstrates the
issue:

With gawk 4.1.1:

bash-4.2$ /extra_disk/tmp/gawk-4.1.1/gawk -v c="zcat 
/usr/share/man/man1/perlapi.1.gz" 'BEGIN {for (i = 1; i <= 134; i++) c | 
getline; print; close(c)}'
.SH "DESCRIPTION"

gzip: stdout: Broken pipe
bash-4.2$ /extra_disk/tmp/gawk-4.1.1/gawk -v c="zcat 
/usr/share/man/man1/perlaix.1.gz" 'BEGIN {for (i = 1; i <= 134; i++) c | 
getline; print; close(c)}'
.SH "DESCRIPTION"

With gawk 4.1.0:

bash-4.2$ /extra_disk/tmp/gawk-4.1.0/gawk -v c="zcat 
/usr/share/man/man1/perlapi.1.gz" 'BEGIN {for (i = 1; i <= 134; i++) c | 
getline; print; close(c)}'
.SH "DESCRIPTION"
bash-4.2$ /extra_disk/tmp/gawk-4.1.0/gawk -v c="zcat 
/usr/share/man/man1/perlaix.1.gz" 'BEGIN {for (i = 1; i <= 134; i++) c | 
getline; print; close(c)}'
.SH "DESCRIPTION"

The first thing to notice is that perlapi.1.gz is a much larger file
than perlaix.1.gz:

bash-4.2$ ls -l perlapi.1.gz perlaix.1.gz 
-rw-r--r-- 1 root root  8613 Nov 11 07:37 perlaix.1.gz
-rw-r--r-- 1 root root 85366 Nov 11 07:37 perlapi.1.gz

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.

Thank you for noticing this and reporting it!

I see the same problem in the master branch currently.  The attached
patch seems to fix it, 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?

Regards,
Andy

pipe.patch
Description: Text document