Oops, gave the RPM package for ksh (which might matter).  I meant to paste in the RPM version for man which is "man-1.6f-24.1.el6.x86_64".

And additionally, I have no problems on RHEL5.x with man and any shell.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Hello, 
please could you test commands:

(cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/ksh.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)

(cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/zip.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)

(cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/wget.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)

and write here the result?

No problems at all running the three commands below:
=======
$ (cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/ksh.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)
KSH(1)                                                                  KSH(1)



NAME
       ksh,  rksh,  pfksh  - KornShell, a standard/restricted command and pro-
       gramming language
[...]
       It is a good idea to leave a space after the comma operator  in  arith-
       metic  expressions  to  prevent the comma from being interpreted as the
       decimal point character in certain locales.




RDS Standard              User Environment Utilities                    KSH(1)
$


$ (cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/zip.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)
ZIP(1L)                                                                ZIP(1L)



NAME
       zip, zipcloak, zipnote, zipsplit - package and compress (archive) files

[...]

$ (cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/wget.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -c -mandoc 2>/dev/null)
WGET(1)                            GNU Wget                            WGET(1)



NAME
       Wget - The non-interactive network downloader.

SYNOPSIS
=======

I take it you're having problem reproducing the problem for
yourself?

I have my login shell set to "/bin/ksh".  I even moved my .profile
out of the way (so no ~/.profile at all) so I know my environment
isn't interfering.  I still get the "Broken pipe" error messages.

Maybe there's a shell, xterm, or psuedo tty setting that's a source
of the problem?  Still with no ~/.profile, I tried logging in on
one of the virtual terminals and still had the problem.  I logged
in via the serial port (/dev/ttyS0) and still had the problem too.
That eliminates most all of the X environment.  However, logging in
remotely from a RHEL5 with ssh did not reproduce the problem!  I
compared "stty -a" output and no real differences.  Any thoughts on
how to isolate this fault further?

Created attachment 425625 [details]
strace of the failure

Reproducible for me with RHEL-6 beta1 and ksh as login shell - without any changes - attached strace shows SIG_PIPE error messages... however - manpage appears to be shown correctly.

The problem seems to be in some environment variables.
Now we can reproduce the problem if the user have ksh as the initial shell (if
it is switched to bash and then to ksh, the bug did not happen).
man command calls just a fork process which realise just the commands which are
in  comment 4 and which works ok. 
Reassigning to ksh.

something rotten is here... I can reproduce this in rhel 6, but can't reproduce with the same version of ksh in rhel 5. I can also confirm that in ksh->bash->ksh everything works fine. I've checked environment variables and ulimits and there are no differences.

anyway, one interesting thing for now is that (t)csh shell and mksh shell produces the same error(bash and zsh are working):
$ useradd -s /bin/csh cshtest
$ su - cshtest -c 'man wget'
Password: 

gzip: stdout: Broken pipe

gzip: stdout: Broken pipe


and another interesting thing:
su - {csh,ksh}test -c 'man wget'
produces error if executed as ordinary user, but when executed as root, everything works

and yet another interesting thing:

using su -c 'man wget' I can reproduce this even with BASH, so I'm not convinced this is exactly ksh's fault

$ su -c 'man wget'
Password: 

gzip: stdout: Broken pipe

gzip: stdout: Broken pipe

In F-13 everything works fine. I've tried to rebuild all F-13 packages (man, groff, gzip, ksh) for rhel6 and problem is still reproducible

I've compared strace of man wget and su -c 'man wget'. Seems in both cases there is SIGPIPE but only in first case error is reported:

broken: su `whoami` -c 'strace -o ~/vystupX.txt -f man wget >/dev/null'
 rt_sigaction(SIGINT, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGHUP, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGTERM, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGXCPU, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGXFSZ, {0x402c10, [HUP INT TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 open("/usr/share/man/man1/wget.1.gz", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4
 fstat(4, {st_mode=S_IFREG|0644, st_size=28281, ...}) = 0
 read(4, ""..., 32768) = 28281
 read(4, "", 4487)                 = 0
 brk(0)                            = 0x15f7000
 brk(0x1618000)                    = 0x1618000
 write(1, "."..., 32768) = 32768
 <... read resumed> "."..., 4096) = 4096
 close(4)                          = 0
 wait4(16496,  <unfinished ...>
 write(1, "n"..., 32768) = -1 EPIPE (Broken pipe)
 --- SIGPIPE (Broken pipe) @ 0 (0) ---
 write(2, "\ngzip: ", 7)           = 7
 write(2, "stdout: Broken pipe\n", 20) = 20
 rt_sigprocmask(SIG_BLOCK, [HUP INT TERM XCPU XFSZ], [], 8) = 0
 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 close(0)                          = 0
 close(1)                          = 0
 close(2)                          = 0
 exit_group(1)                     = ?
 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 16496
 --- SIGCHLD (Child exited) @ 0 (0) ---


works: strace -o ~/vystupZ.txt -f man wget >/dev/null
 rt_sigaction(SIGINT, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGHUP, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGPIPE, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGTERM, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGXCPU, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 rt_sigaction(SIGXFSZ, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, NULL, 8) = 0
 open("/usr/share/man/man1/wget.1.gz", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4
 fstat(4, {st_mode=S_IFREG|0644, st_size=28281, ...}) = 0
 read(4, ""..., 32768) = 28281
 read(4, "", 4487)                 = 0
 brk(0)                            = 0x21b7000
 brk(0x21d8000)                    = 0x21d8000
 write(1, "."..., 32768) = 32768
 <... read resumed> "."..., 4096) = 4096
 write(1, "n"..., 32768) = 32768
 write(1, ""..., 20775 <unfinished ...>
 close(4)                          = 0
 wait4(16577,  <unfinished ...>
 <... write resumed> )             = 4096
 --- SIGPIPE (Broken pipe) @ 0 (0) ---
 rt_sigprocmask(SIG_BLOCK, [HUP INT PIPE TERM XCPU XFSZ], [HUP INT PIPE TERM XCPU XFSZ], 8) = 0
 rt_sigprocmask(SIG_SETMASK, [HUP INT PIPE TERM XCPU XFSZ], NULL, 8) = 0
 rt_sigaction(SIGPIPE, {SIG_DFL, [PIPE], SA_RESTORER|SA_RESTART, 0x33aaa32a40}, {0x402c10, [HUP INT PIPE TERM XCPU XFSZ], SA_RESTORER, 0x33aaa32a40}, 8) = 0
 gettid()                          = 16577
 tgkill(16577, 16577, SIGPIPE)     = 0
 rt_sigreturn(0x40c1)              = 4096
 --- SIGPIPE (Broken pipe) @ 0 (0) ---
 <... wait4 resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGPIPE}], 0, NULL) = 16577
 --- SIGCHLD (Child exited) @ 0 (0) ---


see "rt_sigaction(SIGPIPE,..." which is missing in broken version

You are right, it has nothing to do with ksh itself ... 
Some related topics on internet: 
http://www.mail-archive.com/redhat-devel-list@redhat.com/msg04125.html
http://www.cygwin.com/ml/cygwin/2005-07/msg00912.html
http://www.cygwin.com/ml/cygwin/2005-07/msg00904.html

Common conclusion is that it is broken by design (buffer size of the pipe) and it is not a bug ... in fact only irritating cosmetic thing... moving back to man and closing NOTABUG.

It's not quite the same problem as in the above three links.  In those cases, the user is quitting out of the pager with 'q' prematurely terminating the pager (the app reading the pipe).  A SIGPIPE should be raised in that case since the reader exited (the pager) while the writer of the pipe was still active.  However, in the case I reported, the problem is now happening during normal operation of the man command.  The reader should not be terminating before the writer has finished writing.

Ondrej, I would request the bug be reopened unless I am missing how your three links explains the SIGPIPE behavior in the normal case when the pager is not being prematurely exited.

Ok ... I'm reopening it, but it would be good to know where to reassign the issue. 

It looks like something strange with environment settings for tcsh/ksh ... as starting bash and running ksh again does fix/workaround it. So maybe something with /etc/bashrc - which is not sourced for the case of ksh/tcsh ...

I don't think the issue is in man ... I'll try to check what's wrong with env. settings, so I'm reassigning it to setup, but feel free to reassign it to other suspect if you want.

Thanks.  If I recall the old bug from 2005, the error message would come out after q'ing out of the pager.  In the case I reported, the error message comes out immediately before the man page has even rendered.  You can see this with "man wget 2>&1 | less" and the error message will be at the top of the window.

I'm not sure what to do either without tearing more into it.  What's weird is that when I log in with ssh with my ksh session, there's no problem (no error messages from man).  But when I do it when directly logged in either from an xterm or over the serial port, it happens.

It might be though that ssh is altering the default behavior of SIGPIPE (changing its children's inherited sigmask) hiding the underlying problem.  This would probably also explain why ksh/csh is different than bash/sh if their children's sigmasks are different rather than something in the environment.

If it were my bug, I'd try to figure out why the SIGPIPE is being generated in the first place from what is happening in the man command.  I'd figure out which reader/writer pair in the pipeline the reader is dying then make sure that reader is really dying (exiting) prematurely.  Seems that way from the trace log in comment 11.  Then explore why it's dying prematurely.  Maybe comparing the "strace -f ..." output from RHEL5 and RHEL6 may offer a good clue.  It could even be a kernel issue where something changed by default without realizing the change affected user space.

Created attachment 464974 [details]
proposed patch

There is a problem in man package that isn't related to commands written in comment 4. Man reads characters from pipe to buffer and then closes it. gzip can expose message about broken pipe if file is bigger than buffer.

Proposed patch attached.

We are unable to accommodate a fix for issue in 6.1. Deferring to 6.2.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

I was able to reproduce this bug on RHEL 6.0 final, but not on RHEL 6.1 and 6.2.

Quentin, please, could you confirm this? If it is working on RHEL >= 6.1 without proposed patch, I'll close this bug as WONTFIX.

Thanks,
peter

I think you're right.  It stopped reproducing at some point, and I bet it
was when I upgraded from 6u0->6u1.

I'm glad you also checked it with 6u2 to make sure there wasn't a regression.

Seems to be fixed, so please go ahead and close the ticket.