Bug#627025: perl: data loss in output when both stdout and stderr are redirected to a pipe

[Vincent Lefevre]

reassign 627025 libsvn1
severity 627025 important
retitle 627025 svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe
thanks

On 2011-05-17 21:18:15 +0300, Niko Tyni wrote:
> On Tue, May 17, 2011 at 05:08:33PM +0200, Vincent Lefevre wrote:
> 
> > I think that the cause of the problem may come from that the
> > svn client starts a child process (ssh). This would explain
> > the similarity with the old cvs bug (which occurred only with
> > ssh and stderr redirected to stdout too).
> 
> Right. The ssh process sets its stderr to non blocking mode (in
> ssh_session2_open()), and afterwards when the kernel pipe buffer fills
> up, your print() call to the same duplicated file descriptor fails with
> $! set to EAGAIN.
> 
> If there is a bug here, it's not in perl.

I agree. I suppose that the problem would be the same when using
the svn client API from C.

> Perl is already doing the only thing it can to save you, but you
> don't check the return value of the print() call.

Checking the return value of the print() call would only be useful
to detect the error. But it is not possible to correct the error
as corrupt data have been sent to stdout before the return value
can be tested. And if I tried to output an error message in such
a case, it is also lost in the process.

> Possibly subversion should make a new descriptor for the ssh stderr and
> then shovel data between that and its own stderr.
> 
> Please reassign to subversion if you like, but consider downgrading
> the severity.

Done. Reassigning to libsvn1 since I'm using the API, and I suppose
the problem is there.

-- 
Vincent Lefèvre <vincent at 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)