Subject: bin/5103: SIGPIPE related bugs in 1.3
To: None <gnats-bugs@gnats.netbsd.org>
From: None <woods@mail.weird.com>
List: netbsd-bugs
Date: 03/03/1998 01:07:00
>Number:         5103
>Category:       bin
>Synopsis:       SIGPIPE related bugs in 1.3
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar  2 22:20:00 1998
>Last-Modified:
>Originator:     Greg A. Woods
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Release:        1.3
>Environment:

System: NetBSD most 1.3 NetBSD 1.3 (GENERIC_SCSI3) #0: Thu Jan 1 19:03:39 MET 1998 pk@flambard:/usr/src1/sys/arch/sparc/compile/GENERIC_SCSI3 sparc

>Description:

Several utilities have begun to exhibit failures related to incorrect
handling of SIGPIPE.  These errors seem independent of the shell being
used (tested with the standard /bin/sh, /bin/ksh, and even /bin/csh).

This problem was not present in 1.2 (tested 1.2G on i386).

I'm not sure if this is a user-land, library, or kernel problem, and I'm
not yet sure if the following examples are even related (though by
virtue of both being present in 1.3 and not in 1.2, they at least have
something in common!).

It would seem that only programs which check return values from writes
will ever notice anything wrong.  It's almost as if SIGPIPE is never
delivered....

This bug rarely causes major failures in day-to-day software development
use, but it can be responsible for strange delays and pauses depending
on what you're doing.  However for scripts or programs that expect to be
able to squelch a large or infinite amount of output, this problem can
be highly detrimental or even cause infinite execution.

>How-To-Repeat:

The following command hangs forever after printing one 'y':

	yes | head -1

It should terminate silently after that one line is printed.  This
problem prevails with all pipelines where the reader stops and closes
stdin (perhaps by exiting).

If you run something resembling the following command where the fgrep
will find many more lines of output than just one page, and you quit
'less' after the first page you'll get many "fgrep: writing output:
Broken pipe" errors:

	fgrep 'common-string' lots and lots of files | less

>Fix:

	unknown (but I'm looking into it!)

>Audit-Trail:
>Unformatted: