Unreliability in process output

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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?


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

Re: Unreliability in process output

Kim Storm
In reply to this post by Richard Stallman
Richard Stallman <[hidden email]> 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 <[hidden email]> http://www.cua.dk



_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

Re: Unreliability in process output

Andreas Schwab
In reply to this post by Richard Stallman
Richard Stallman <[hidden email]> 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, [hidden email]
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."


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

Re: Unreliability in process output

Peter Heslin
Andreas Schwab <[hidden email]> 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



_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

Re: Unreliability in process output

Andreas Schwab
[hidden email] writes:

> Andreas Schwab <[hidden email]> 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, [hidden email]
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."


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

Re: Unreliability in process output

Richard Stallman
In reply to this post by Andreas Schwab
    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.


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

Re: Unreliability in process output

Richard Stallman
In reply to this post by Kim Storm
    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.




_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

Re: Unreliability in process output

Andreas Schwab
Richard Stallman <[hidden email]> 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, [hidden email]
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."


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

Re: Unreliability in process output

Robert J. Chassell
In reply to this post by Kim Storm
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                        
    [hidden email]                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel