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

[Daryl F]

On Thu, 24 Apr 2014, Andrew J. Schorr wrote:

> 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.

No problem. I didn't present the issue very well.

> 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.

Yes, it did produce the correct results.

> > 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.

Excellent problem solving. I never thought about the file size difference.

> 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?

man execl is aliased to man exec(3) which states "The functions described 
in this manual page are front-ends for execve(2)"

man execve(2) on my distro does say the signals are reset to default.

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.

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.

Thanks for the patch. I've opened a bug with the CRUX distro team to 
include it until the patch is incorporated in gawk.


Regards,

-Daryl