Lost process output in pipe between Emacs and CVS

[Stefan Monnier]

Over the last few years, I've had several times people complain about
PCL-CVS' diff output being incorrect (with parts missing).

Since the FSF' kerberos server was down, I had to switch to SSH
access and finally for the first time I've experienced this lossage
first hand.

Assuming that the problem is unrelated to CVS or to SSH,
it seems that the only difference between when it worked and now
is that access via Kerberos is significantly faster (at least
in terms of latency, but maybe also bandwidth).  But from CVS'
point of view, the difference is more significant since Kerberos
is directly supported (I use the :gserver: access method)
whereas SSH goes through an external process.

So it looks a bit like a race condition, but the problem is that
it is surprisingly reproducible.

When I open PCL-CVS on the emacs/src directory and hit `=' on
the `minibuf.c' file, I get a *vc-diff* buffer that contains
the first 4096 chars of the  diff output and the last 898
for a total size of 4964.

By contrast

        % cvs diff src/minibuf.c |(sleep 120; wc)
            768    3146   21472

so 16478 were lost somewhere on the way.  I tried to investigate
a bit more by placing a breakpoint on emacs_read and then doing

        p read (fildes, buf, nbyte)

and I see the exact same lossage: the first four calls return
1024 chars each (the first 4096 of the output) and the next one
returns the last 898 chars of the output (and the next one returns 0).

Another notable thing is that this whole problem disappears if I
change PCL-CVS to use a pty rather than a pipe for the process' output.
(I noticed it because the problem doesn't appear with VC which is
not careful to use a pipe).

Now my direct `read' calls from GDB make me believe that maybe the
problem is not in Emacs, but in CVS instead (I use cvs-1.11.1p1
from the Redhat distribution, with a mix of Redhat-7.2
and Redhat-7.3 GNU/Linux system).

But the fact that `cvs diff src/minibuf.c |(sleep 120; wc)' works
correctly make me think that maybe it is a bug in Emacs.

Could anybody help me out with insight/hints/patches/chocolates ?


        Stefan