GNU bug report logs - #24531
process-send-string seems to truncate lines over 4096 characters

Previous Next

To reply to this bug, email your comments to 24531 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: talwrii talwrii <talwrii <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: process-send-string seems to truncate lines over 4096 characters
Date: Sat, 24 Sep 2016 18:38:18 -0500

[Message part 1 (text/plain, inline)]

=== Repro ===

i. Download attached el file
ii. Read it to ensure I am not hacking your computer
iii. In the same directory run

emacs -Q --eval '(progn (load-file "line-repro.el") (message (format "%S"
(repro))))' -nw --batch

As the last line of output I get

(3005 4100 6006)

I wouild expect this 4100 to be 5005

The third value indicates it is the line that gets truncated rather than
the string

=== Version details ===

In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of
2016-04-08 on binet, modified by Debian Windowing system distributor `The
X.Org Foundation', version 11.0.11804000 System Description: Debian
GNU/Linux testing (stretch) Configured using: `configure --build
x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
--build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
--with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g
-O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall'
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro' Important
settings: value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8-unix

[Message part 2 (text/html, inline)]

[line-repro.el (text/x-emacs-lisp, attachment)]

Message #8 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Thien-Thi Nguyen <ttn <at> gnu.org>
To: talwrii talwrii <talwrii <at> gmail.com>
Cc: 24531 <at> debbugs.gnu.org
Subject: Re: bug#24531: process-send-string seems to truncate lines over 4096
 characters
Date: Mon, 26 Sep 2016 10:36:21 +0200

[Message part 1 (text/plain, inline)]

() talwrii talwrii <talwrii <at> gmail.com>
() Sat, 24 Sep 2016 18:38:18 -0500

   (3005 4100 6006)

   I wouild expect this 4100 to be 5005

See variable ‘process-connection-type’.  When i add:

 (setq process-connection-type nil)

to the beginning of line-repo.el, i see the expected output.

--
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (type via)
   (case type
     (technical (eq 'mailing-list via))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: 24531 <at> debbugs.gnu.org
Subject: Re: bug#24531: process-send-string seems to truncate lines over 4096
 characters
Date: Mon, 26 Sep 2016 12:23:14 +0200

On Sep 26 2016, Thien-Thi Nguyen <ttn <at> gnu.org> wrote:

> () talwrii talwrii <talwrii <at> gmail.com>
> () Sat, 24 Sep 2016 18:38:18 -0500
>
>    (3005 4100 6006)
>
>    I wouild expect this 4100 to be 5005
>
> See variable ‘process-connection-type’.  When i add:
>
>  (setq process-connection-type nil)
>
> to the beginning of line-repo.el, i see the expected output.

That could be the effect of the TTY ICANON handling.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Message #20 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 24531 <at> debbugs.gnu.org, 6149 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#24531: process-send-string seems to truncate lines over
 4096 characters
Date: Thu, 20 Jul 2023 16:15:11 -0400

[Message part 1 (text/plain, inline)]

I see that this bug is about 13 years old.  I think there's a pretty
obvious solution: process-connection-type should default to nil.
Otherwise this is a footgun just waiting to happen for anyone writing
process-interaction code in Emacs.

But if we don't do that, we should at least document it.  See my
attached patch.

Btw, just to feed the fire, here's my own reproducer:

(with-temp-buffer
  (make-process :name "broken" :buffer (current-buffer) :command '("cat"))
  (process-send-string nil (make-string 10000 ?x))
  (process-send-eof)
  (sit-for 1)
  (cons (point-min) (point-max)))

[0001-Include-warning-about-long-line-truncation-in-proces.patch (text/x-patch, inline)]

From dcfd129b3f08273a8b0705f03b6074443a7a33c1 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 20 Jul 2023 16:13:56 -0400
Subject: [PATCH] Include warning about long line truncation in
 process-send-string

Maybe we can't fix this.  But we can at least warn the user about it!
To have no warning anywhere about this default behavior which silently
discards data, is very user-hostile.

* src/process.c (Fprocess_send_string): Include a warning about long
line truncation (bug#6149)
---
 src/process.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/process.c b/src/process.c
index 67d1d3e425f..82ace1b3a41 100644
--- a/src/process.c
+++ b/src/process.c
@@ -6755,6 +6755,8 @@ DEFUN ("process-send-string", Fprocess_send_string, Sprocess_send_string,
 of which depends on the process connection type and the operating
 system), it is sent in several bunches.  This may happen even for
 shorter strings.  Output from processes can arrive in between bunches.
+If the process connection type is `pty', then long lines present in
+STRING may be truncated depending on the operating system.
 
 If PROCESS is a non-blocking network process that hasn't been fully
 set up yet, this function will block until socket setup has completed.  */)
-- 
2.39.3

Message #23 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 24531 <at> debbugs.gnu.org, 6149 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#24531: process-send-string seems to truncate lines over
 4096 characters
Date: Thu, 20 Jul 2023 17:21:53 -0400

> I see that this bug is about 13 years old.  I think there's a pretty
> obvious solution: process-connection-type should default to nil.

In practice, that can't fly because it'll break existing code.

Also I don't think either value of `process-connection-type` is a good
option.  IOW, I think that the connection type should be a mandatory
argument when creating an async process (except maybe for those
processes with no input/output).

So maybe, the default value of `process-connection-type` should be
`unspecified` and the process creation code should emit a warning when
creating a process whose connection type is `unspecified` (just
a warning, tho: it should then pursue execution as if that value was t,
as usual, so as to preserve compatibility).


        Stefan

Message #26 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 24531 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, 6149 <at> debbugs.gnu.org,
 jidanni <at> jidanni.org
Subject: Re: bug#6149: bug#24531: process-send-string seems to truncate lines
 over 4096 characters
Date: Fri, 21 Jul 2023 08:39:52 +0300

> Cc: 24531 <at> debbugs.gnu.org, 6149 <at> debbugs.gnu.org, jidanni <at> jidanni.org
> Date: Thu, 20 Jul 2023 17:21:53 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> > I see that this bug is about 13 years old.  I think there's a pretty
> > obvious solution: process-connection-type should default to nil.
> 
> In practice, that can't fly because it'll break existing code.

Indeed.  A large portion (I think the majority, but I'm not sure) of
Lisp programs that use bidirectional communications with async
subprocesses actually _want_ the PTY interface, because they act as
GUI front-ends to other programs.  Think "M-x term", "M-x gdb",
inferior-python-mode, etc.  Even "M-x grep" and the likes need that
because they rely on default color output, which only happens if Grep
is connected to a terminal device.  Some of the Emacs features based
on this don't work or don't work well on MS-Windows because Windows
only supports pipes.  Do we really want such semi-broken behavior on
GNU and Unix systems?

The number of applications that (a) don't need console-like behavior
and (b) need to send larger-than-4KB buffers to sub-processes is quite
small.  Which is why this issue comes up only very rarely.  So making
pipes the default will fix a very small fraction of applications, and
break the vast majority -- clearly a wrong balance.

> Also I don't think either value of `process-connection-type` is a good
> option.  IOW, I think that the connection type should be a mandatory
> argument when creating an async process (except maybe for those
> processes with no input/output).

If we go that way, we should start by specifying :connection-type for
all the uses of make-process and start-process we have in the core.
It's a large job, but before it is done we cannot in good faith make
such an incompatible transition.

> So maybe, the default value of `process-connection-type` should be
> `unspecified` and the process creation code should emit a warning when
> creating a process whose connection type is `unspecified` (just
> a warning, tho: it should then pursue execution as if that value was t,
> as usual, so as to preserve compatibility).

Something like that, yes.

But I'm actually wondering how come modern Linux kernels don't have a
way of lifting this restriction, or at least enlarging the limit so it
makes the problem even less frequent.  Is there some inherent
limitation that this must be 4KB and nothing larger?

Message #29 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24531 <at> debbugs.gnu.org, 6149 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, jidanni <at> jidanni.org
Subject: Re: bug#24531: process-send-string seems to truncate lines over
 4096 characters
Date: Fri, 21 Jul 2023 09:58:38 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 24531 <at> debbugs.gnu.org, 6149 <at> debbugs.gnu.org, jidanni <at> jidanni.org
>> Date: Thu, 20 Jul 2023 17:21:53 -0400
>> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> > I see that this bug is about 13 years old.  I think there's a pretty
>> > obvious solution: process-connection-type should default to nil.
>> 
>> In practice, that can't fly because it'll break existing code.
>
> Indeed.

I agree that we probably can't change the default.  However...

> A large portion (I think the majority, but I'm not sure) of
> Lisp programs that use bidirectional communications with async
> subprocesses actually _want_ the PTY interface, because they act as
> GUI front-ends to other programs.  Think "M-x term", "M-x gdb",
> inferior-python-mode, etc.  Even "M-x grep" and the likes need that
> because they rely on default color output, which only happens if Grep
> is connected to a terminal device.  Some of the Emacs features based
> on this don't work or don't work well on MS-Windows because Windows
> only supports pipes.  Do we really want such semi-broken behavior on
> GNU and Unix systems?
>
> The number of applications that (a) don't need console-like behavior
> and (b) need to send larger-than-4KB buffers to sub-processes is quite
> small.  Which is why this issue comes up only very rarely.  So making
> pipes the default will fix a very small fraction of applications, and
> break the vast majority -- clearly a wrong balance.

I see your point, but at the same time, the PTY interface on its own is
not sufficient to make these applications work, not at all.  Specialized
modes are necessary to make M-x term (to implement a terminal) and M-x
grep (to parse ANSI color codes) and other such programs work.  Running
things in a PTY without such specialized code doesn't give you anything,
AFAIK, because a PTY alone is far from enough to make the Emacs end
behave like a terminal.  So such programs need to be aware and careful
about such things anyway, and need additional infrastructure on top of
make-process.  So the default being "pty" gives such programs very
little: it doesn't save them any complexity.

Programs that just want to do some data processing with a subprocess, on
the other hand, work fine with just make-process alone, they need no
additional infrastructure, just process-send-string and reading directly
from the process buffer.  The default being "pipe" would take away a big
footgun for such programs, since it's easy to forget that and then have
a silently wrong program which will fail once you get large input.

>> Also I don't think either value of `process-connection-type` is a good
>> option.  IOW, I think that the connection type should be a mandatory
>> argument when creating an async process (except maybe for those
>> processes with no input/output).
>
> If we go that way, we should start by specifying :connection-type for
> all the uses of make-process and start-process we have in the core.
> It's a large job, but before it is done we cannot in good faith make
> such an incompatible transition.

I can do that.

However, what about my patch adding a warning about this to
process-send-string?  I think that is independently valuable.  Right now
we have no documentation of this problem...

>> So maybe, the default value of `process-connection-type` should be
>> `unspecified` and the process creation code should emit a warning when
>> creating a process whose connection type is `unspecified` (just
>> a warning, tho: it should then pursue execution as if that value was t,
>> as usual, so as to preserve compatibility).
>
> Something like that, yes.
>
> But I'm actually wondering how come modern Linux kernels don't have a
> way of lifting this restriction, or at least enlarging the limit so it
> makes the problem even less frequent.  Is there some inherent
> limitation that this must be 4KB and nothing larger?

Unfortunately from looking at Linux the limit of 4096 seems to be
hardcoded.

Message #32 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 24531 <at> debbugs.gnu.org, 6149 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 jidanni <at> jidanni.org
Subject: Re: bug#24531: process-send-string seems to truncate lines over
 4096 characters
Date: Fri, 21 Jul 2023 17:18:34 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  24531 <at> debbugs.gnu.org,
>    6149 <at> debbugs.gnu.org,  jidanni <at> jidanni.org
> Date: Fri, 21 Jul 2023 09:58:38 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > The number of applications that (a) don't need console-like behavior
> > and (b) need to send larger-than-4KB buffers to sub-processes is quite
> > small.  Which is why this issue comes up only very rarely.  So making
> > pipes the default will fix a very small fraction of applications, and
> > break the vast majority -- clearly a wrong balance.
> 
> I see your point, but at the same time, the PTY interface on its own is
> not sufficient to make these applications work, not at all.  Specialized
> modes are necessary to make M-x term (to implement a terminal) and M-x
> grep (to parse ANSI color codes) and other such programs work.  Running
> things in a PTY without such specialized code doesn't give you anything,
> AFAIK, because a PTY alone is far from enough to make the Emacs end
> behave like a terminal.  So such programs need to be aware and careful
> about such things anyway, and need additional infrastructure on top of
> make-process.  So the default being "pty" gives such programs very
> little: it doesn't save them any complexity.

That Emacs needs to do something doesn't invalidate my point.  My
point is that communications via a PTY is a necessary (though a
sufficient) condition for these features.  Basically, you cannot use
pipes for any interactive feature, because pipes are buffered.

> However, what about my patch adding a warning about this to
> process-send-string?  I think that is independently valuable.  Right now
> we have no documentation of this problem...

This should be documented in the ELisp manual, and in more detail, not
just as a vague warning.

Message #35 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24531 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, 6149 <at> debbugs.gnu.org,
 jidanni <at> jidanni.org
Subject: Re: bug#6149: bug#24531: process-send-string seems to truncate
 lines over 4096 characters
Date: Fri, 21 Jul 2023 11:09:17 -0400

>> Also I don't think either value of `process-connection-type` is a good
>> option.  IOW, I think that the connection type should be a mandatory
>> argument when creating an async process (except maybe for those
>> processes with no input/output).
> If we go that way, we should start by specifying :connection-type for
> all the uses of make-process and start-process we have in the core.

That would be a good start, yes.


        Stefan

Message #38 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 24531 <at> debbugs.gnu.org, 6149 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, jidanni <at> jidanni.org
Subject: Re: bug#6149: bug#24531: process-send-string seems to truncate lines
 over 4096 characters
Date: Thu, 27 Jul 2023 04:48:18 +0300

On 21/07/2023 16:58, Spencer Baugh wrote:
>> But I'm actually wondering how come modern Linux kernels don't have a
>> way of lifting this restriction, or at least enlarging the limit so it
>> makes the problem even less frequent.  Is there some inherent
>> limitation that this must be 4KB and nothing larger?
> Unfortunately from looking at Linux the limit of 4096 seems to be
> hardcoded.

If some syscall or etc limits the length of a string to 4096, can't we 
detect this case, split the string and emit said call multiple times?

This function's docstring already mentions the case of

  If STRING is larger than the input buffer of the process, ...
  it is sent in several bunches

Message #41 received at 24531 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 24531 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, 6149 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, jidanni <at> jidanni.org
Subject: Re: bug#6149: bug#24531: process-send-string seems to truncate lines
 over 4096 characters
Date: Thu, 27 Jul 2023 08:41:52 +0300

> Date: Thu, 27 Jul 2023 04:48:18 +0300
> Cc: 24531 <at> debbugs.gnu.org, 6149 <at> debbugs.gnu.org,
>  Stefan Monnier <monnier <at> iro.umontreal.ca>, jidanni <at> jidanni.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> If some syscall or etc limits the length of a string to 4096, can't we 
> detect this case, split the string and emit said call multiple times?
> 
> This function's docstring already mentions the case of
> 
>    If STRING is larger than the input buffer of the process, ...
>    it is sent in several bunches

AFAIU, that is based on the errno value returned by a 'write' call
which attempts to write too many bytes (see the would_block function).
I guess writes to PTYs don't do that?

Paul, do you know anything about that?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.