You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Vincent Lefevre <vi...@vinc17.net> on 2011/05/30 15:30:25 UTC
svn client with ssh: data loss in output when both stdout and stderr
are redirected to a pipe
I've found the following bug with Subversion 1.6.16:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025
The problem is: With the svn+ssh scheme, a ssh process is started and
sets its stderr to non-blocking mode. When executing an API-based svn
client with both stdout and stderr redirected to a pipe, output to
stdout (and stderr too, I suppose) fails with EAGAIN instead of
blocking when the pipe buffer is full. See the above URL for more
information.
"svn log 2>&1 | less" on a (big enough) svn+ssh working copy fails to
output the full log. It sometimes ends with:
svn: Write error: Resource temporarily unavailable
I think the above test should be sufficient, but just in case, I've
attached (this is what I used for my Debian bug report):
* a shell script bigrep to create a repository and a working copy.
* a Perl script svn2log (based on SVN::Client) to reproduce the bug.
To reproduce the bug:
./bigrep
./svn2log bigrep-wc 2>&1 | less
and hit the [End] key. One generally gets:
[...]
2990
2991
2992
29
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
lines 14957-15015/15015 (END)
Also:
tomate% ./svn2log bigrep-wc 2>&1 | wc
26521 26553 123083
tomate% ./svn2log bigrep-wc 2>&1 | wc
25701 25733 118987
tomate% ./svn2log bigrep-wc 2>&1 | wc
25702 25734 118987
tomate% ./svn2log bigrep-wc 2>&1 | wc
30012 30046 139467
tomate% ./svn2log bigrep-wc 2>&1 | wc
30012 30046 139467
tomate% ./svn2log bigrep-wc 2>&1 | wc
26521 26553 123083
As suggested by Niko Tyni:
Possibly subversion should make a new descriptor for the ssh stderr
and then shovel data between that and its own stderr.
You can also see what cvs did, because it had the same problem.
--
Vincent Lef�vre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Ar�naire project (LIP, ENS-Lyon)
Re: svn client with ssh: data loss in output when both stdout and
stderr are redirected to a pipe
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2011-05-30 16:27:04 +0200, Stefan Sperling wrote:
> please feel free to file an issue on this bug.
OK: http://subversion.tigris.org/issues/show_bug.cgi?id=3906
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: svn client with ssh: data loss in output when both stdout and
stderr are redirected to a pipe
Posted by Stefan Sperling <st...@elego.de>.
On Mon, May 30, 2011 at 04:20:29PM +0200, Vincent Lefevre wrote:
> In my bug report above, there should be no broken pipe or any
> other error (as long as one uses "less" + [End] key, or some
> command like wc, which reads the full input stream). It occurs
> only when stderr is redirected to stdout, and only when ssh is
> used (as in the svn+ssh scheme).
Hi Vincent,
please feel free to file an issue on this bug.
I don't think it's going to be fixed in 1.7.0 (there are more important
release blocking issues to work on) but we could consider fixing this
in some 1.7 patch release.
Re: svn client with ssh: data loss in output when both stdout and
stderr are redirected to a pipe
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2011-05-30 09:58:45 -0400, Mark Phippard wrote:
> 2011/5/30 Vincent Lefevre <vi...@vinc17.net>:
> > I've found the following bug with Subversion 1.6.16:
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025
> >
> > The problem is: With the svn+ssh scheme, a ssh process is started and
> > sets its stderr to non-blocking mode. When executing an API-based svn
> > client with both stdout and stderr redirected to a pipe, output to
> > stdout (and stderr too, I suppose) fails with EAGAIN instead of
> > blocking when the pipe buffer is full. See the above URL for more
> > information.
> >
> > "svn log 2>&1 | less" on a (big enough) svn+ssh working copy fails to
> > output the full log. It sometimes ends with:
> >
> > svn: Write error: Resource temporarily unavailable
> >
> > I think the above test should be sufficient, but just in case, I've
> > attached (this is what I used for my Debian bug report):
>
> This sounds similar to this bug:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3014
No, this is a different bug.
Bug 3014 is about an error message printed instead of using the
exit status to signal the broken pipe. The broken pipe is normal,
and it occurs even when stderr is not redirected to stdout, and
even without ssh.
In my bug report above, there should be no broken pipe or any
other error (as long as one uses "less" + [End] key, or some
command like wc, which reads the full input stream). It occurs
only when stderr is redirected to stdout, and only when ssh is
used (as in the svn+ssh scheme).
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: svn client with ssh: data loss in output when both stdout and
stderr are redirected to a pipe
Posted by Mark Phippard <ma...@gmail.com>.
2011/5/30 Vincent Lefevre <vi...@vinc17.net>:
> I've found the following bug with Subversion 1.6.16:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025
>
> The problem is: With the svn+ssh scheme, a ssh process is started and
> sets its stderr to non-blocking mode. When executing an API-based svn
> client with both stdout and stderr redirected to a pipe, output to
> stdout (and stderr too, I suppose) fails with EAGAIN instead of
> blocking when the pipe buffer is full. See the above URL for more
> information.
>
> "svn log 2>&1 | less" on a (big enough) svn+ssh working copy fails to
> output the full log. It sometimes ends with:
>
> svn: Write error: Resource temporarily unavailable
>
> I think the above test should be sufficient, but just in case, I've
> attached (this is what I used for my Debian bug report):
This sounds similar to this bug:
http://subversion.tigris.org/issues/show_bug.cgi?id=3014
--
Thanks
Mark Phippard
http://markphip.blogspot.com/