Unreliability in process output

Unreliability in process output

[Richard Stallman]

After emacs -Q, visiting src/window.c and then doing C-x v l gives
unreliable results.  Large chunks of the buffer are missing.  Which
parts are missing varies each time, but the first missing chunk seems
to start on a 4096-character boundary.

The problem still happens if process-adaptive-read-buffering is nil
and coding-system-for-read is no-conversion.  I've determined that the
variable carryover in read_process_output is always zero in that mode.

When I tried this with a breakpoint at read_process_output, and paused
for some time in that breakpoint, the text obtained consisted of the
first chunk plus a little more; nearly all was lost.

Stepping through read_process_output showed that the only calls
to emacs_read were from read_process_output, and that the text they
read was the text that appeared in the buffer.  Somehow the rest
of the text is disappearing.

Similar problems happen with an executable I compiled almost 3 years
ago.  It is not a newly introduced problem.

Can anyone else observe this problem?  Can anyone make more headway
debugging this?

Unreliability in process output

[Nick Roberts]

 > After emacs -Q, visiting src/window.c and then doing C-x v l gives
 > unreliable results.  Large chunks of the buffer are missing.  Which
 > parts are missing varies each time, but the first missing chunk seems
 > to start on a 4096-character boundary.

Isn't this the problem with ssh referred to in INSTALL.CVS? It was discussed
on emacs-devel last October with the subject vc-version-other-window.

Nick

Re: Unreliability in process output

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> After emacs -Q, visiting src/window.c and then doing C-x v l gives
> unreliable results.  Large chunks of the buffer are missing. 

> Can anyone else observe this problem?  Can anyone make more headway
> debugging this?

It's an old problem with CVS over SSH -- it has been discussed
before on the mailing list.


Here is what INSTALL.CVS has to say about the topic:

Note on using SSH to access the CVS repository from inside Emacs
----------------------------------------------------------------

Write access to the CVS repository requires using SSH v2.

If you execute cvs commands inside Emacs, specifically if you use
pcl-cvs, output from CVS may be lost due to a problem in the
interface between ssh, cvs, and libc.  Corrupted checkins have
also been rumored to have happened.

To fix the problem, save the following script into a file, make it
executable, and set CVS_RSH to the file name of the script:

#!/bin/bash
exec 2> >(exec cat >&2 2>/dev/null)
exec ssh "$@"

This may be combined with the following entry in ~/.ssh/config to
simplify accessing the CVS repository:

Host subversions.gnu.org
     Protocol 2
     ForwardX11 no
     User YOUR_USERID

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Unreliability in process output

[Richard Stallman]

    It's an old problem with CVS over SSH -- it has been discussed
    before on the mailing list.

Thanks.  I will try this solution.

However, we simply must correct the problem.  Could you tell me the
dates of that discussion so I can find the relevant mail?  I want to
see if I can persuade someone to make a change that will solve the
problem.

Re: Unreliability in process output

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     It's an old problem with CVS over SSH -- it has been discussed
>     before on the mailing list.
>
> Thanks.  I will try this solution.
>
> However, we simply must correct the problem.  Could you tell me the
> dates of that discussion so I can find the relevant mail?  I want to
> see if I can persuade someone to make a change that will solve the
> problem.

See <http://lists.gnu.org/archive/html/bug-cvs/2002-07/msg00423.html> for
a good explanation.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Unreliability in process output

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Wed, 2005 Jun  8  12:07 UTC
GNU Emacs 22.0.50.21 (i686-pc-linux-gnu, GTK+ Version 2.6.4)
built using bootfast
started with

    emacs/src/emacs -Q -D

After running PCL-CVS and vc-annotate

    > After emacs -Q, visiting src/window.c and then doing C-x v l gives
    > unreliable results.  Large chunks of the buffer are missing. 

The same occurs with me, but only when I do this with an instance of
Emacs that has my .emacs file.  Then the beginning of lisp/files.el was
6553 bytes in even after applying the fixes that Kim Storm mentioned
from INSTALL.CVS and the beginning of the file appeared.

In the past, without that fix,     emacs/src/emacs -Q -D  
also missed part of the buffer.

But after applying those fixes from INSTALL.CVS     emacs/src/emacs -Q -D  
appears to work consistently.

I lack the time for the next few days to figure out what is happening
in my .emacs file.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Unreliability in process output

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> After emacs -Q, visiting src/window.c and then doing C-x v l gives
> unreliable results.  Large chunks of the buffer are missing.  Which
> parts are missing varies each time, but the first missing chunk seems
> to start on a 4096-character boundary.

Do you happen to run Linux 2.6.10?  That might be the same issue that
Stefan observed recently (see topic "File botched up using Tramp"
<http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg01468.html>).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Unreliability in process output

[public]

Andreas Schwab <schwab@suse.de> writes:
> Do you happen to run Linux 2.6.10?  That might be the same issue that
> Stefan observed recently (see topic "File botched up using Tramp"
> <http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg01468.html>).

Just to add another data point: I have observed file corruption when
using tramp to edit files on a remote machine which happens to be
running a 2.6.10 kernel, even when the local machine on which Emacs is
running has an unaffected kernel version.

Peter

Re: Unreliability in process output

[Andreas Schwab]

public@heslin.eclipse.co.uk writes:

> Andreas Schwab <schwab@suse.de> writes:
>> Do you happen to run Linux 2.6.10?  That might be the same issue that
>> Stefan observed recently (see topic "File botched up using Tramp"
>> <http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg01468.html>).
>
> Just to add another data point: I have observed file corruption when
> using tramp to edit files on a remote machine which happens to be
> running a 2.6.10 kernel, even when the local machine on which Emacs is
> running has an unaffected kernel version.

Yes, the bug only manifests at the remote side, because this where the PTY
communication happens that triggers the bug.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Unreliability in process output

[Richard Stallman]

    Do you happen to run Linux 2.6.10?  That might be the same issue that
    Stefan observed recently (see topic "File botched up using Tramp"
    <http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg01468.html>).

It is version 2.4.23.