Bug#627025: perl: data loss in output when both stdout and stderr are redirected to a pipe
Niko Tyni
ntyni at debian.org
Tue May 17 18:18:15 UTC 2011
On Tue, May 17, 2011 at 05:03:18AM +0200, Vincent Lefevre wrote:
> Package: perl
> Version: 5.12.3-6
> Severity: grave
> Justification: causes non-serious data loss
> When stdout and stderr are both redirected to a pipe, some of the
> output data can be lost!
> my $ctx = new SVN::Client;
> $ctx->log(\@ARGV, 'HEAD', 1, 0, undef, \&log_receiver);
>
> sub log_receiver
> {
> print "@_[0..4]\n";
> }
> The problem doesn't occur if I don't redirect stderr.
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. Perl is already doing the only
thing it can to save you, but you don't check the return value of the
print() call.
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.
--
Niko Tyni ntyni at debian.org
More information about the Perl-maintainers
mailing list