Bug 79310
Summary: | write to pipe doesn't block | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Sjoerd Mullender <sjoerd> | ||||||
Component: | cvs | Assignee: | Martin Stransky <stransky> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 2 | CC: | alan, bill, dme49, mattdm | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | i686 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2005-04-26 16:15:45 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Sjoerd Mullender
2002-12-09 22:39:26 UTC
Created attachment 88085 [details]
tar file containing strace output of cvs and less commands from bug report
This bug still exists in Fedora Core 1 Test 3 with kernel-2.4.22-1.2115.nptl. I just tried the command on a 825 line file. When scrolled to the bottom, less reported that there were only 217 lines (3 for the header, and so only 214 for the rest of the file). Still present in Fedora Core 1 with kernel-2.4.22-1.2174.nptl. This is a very annoying bug since I get bit by it almost every when I try to view annotation from within XEmacs. I'm also not happy that this bug is over a year old and apparently nobody has looked at it. What is the use of submitting bug reports? This bug is still present in Fedora Core 2 with kernel-smp-2.6.6-1.435. This bug was reported a year-and-a-half ago and nobody has even acknowledged the report yet! It is trivial to test! I've never been able to duplicate this for one. Do you use some particularly weird shell perhaps ? I noticed the problem first in XEmacs (vc-annotate command). No shell involved there. I was able to reproduce it in my own private shell (originally based on the Bourne shell), but I can also reproduce it in bash. I hadn't mentioned it, the CVS repositories I use for this are all remote repositories accessed with SSH. Can't reproduce it with bash and ssh repositories either. Can you get me an strace following forks including that of the shell itself ? That way I can see which task sets the pipe to nonblocking Created attachment 101257 [details]
strace output of bash showing problematic invocation
There is an old attachment with strace output of cvs and less.
I'll add a newly created strace output using this command:
strace -o @bash -f bash -c 'cvs annotate xec.c 2>&1 | (sleep 2; less)'
This invokation also resulted in a truncated result. This was created on FC1.
I'm chasing a similar effect with truncated output from rsync -n over ssh. For what it's worth, in my case the problem is not kernel-related, but is an unfortunate side-effect of the "2>&1 | [something slow, like tee]" idiom when combined with ssh. It seems that rsync's child ssh sets its stdERR non-blocking, and that stderr has been inherited unchanged from the top-level rsync. (The rsync has supplied pipes for its child's stdin and stdout, but left the stderr alone. The code that does this is commented as being derived from CVS code, which is a possible connection to the original report; see rsync-2.6.2/pipe.c::piped_child()) Because of the "2>&1", the top-level stderr is a dup of the top-level stdout, so ssh has inadvertantly made rsync's stdOUT non-blocking. Rsync is not expecting that, and does not check the return code from fflush(stdout), so it can silently drop lines from stdout. (See the end of rsync-2.6.3/log.c::rwrite()) For me, removing the "2>&1" from the command restores the full output, at the cost of not capturing stderr. The original reporter might like to try the same experiment. (Versions: OpenSSH_3.7.1p2, rsync version 2.6.2) See also http://groups.google.com/groups?th=e4df2fdc1f4f4950 and http://sources.redhat.com/ml/bug-glibc/2002-08/msg00041.html Dropping the (equivalent of) 2>&1 has been my workaround for ages. David's analysis is consistent with what I have seen, so perhaps this is not a kernel bug after all. I have no clues (assuming it still isn't fixed with latest updates). Reassigning to 'bash', maybe Tim has some insight. reflecting change in comment 12 No idea what happened to the comment I already wrote when I reassigned this to cvs, but here's a summary: Read the link: http://sources.redhat.com/ml/bug-glibc/2002-08/msg00041.html Paul Eggart thinks CVS needs changing, and I tend to agree. Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match. I can't reproduce the bug in FC3+updates anymore, so the report can be closed, as far as I am concerned. |