GNU bug report logs - #13290
24.2.91; [PATCH] Comint can stall emacs with non-trivial input senders

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13290 in the body.
You can then email your comments to 13290 AT debbugs.gnu.org in the normal way.

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

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

From: Vitalie Spinu <spinuvit <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2.91; [PATCH] Comint can stall emacs with non-trivial input senders
Date: Thu, 27 Dec 2012 22:49:01 +0100

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

Hi, 

Comint can stall emacs while waiting for subproces output. I attach a
trivial patch.

Here is a short explanation. First comint calls comint-input-sender 

╭──────── #1842 ─ /home/vitoshka/TVC/emacs/lisp/comint.el ──
│         (let ((comint-input-sender-no-newline no-newline))
│           (funcall comint-input-sender proc input))
╰──────── #1843 ─

Then, if process echoes, comint first waits for process output:

╭──────── #1850 ─ /home/vitoshka/TVC/emacs/lisp/comint.el ──
│             (while (and (accept-process-output proc)
│                         (> (+ comint-last-input-end echo-len)
│                            (point-max))
╰──────── #1852 ─

The problem is that, occasionally, comint-input-sender might be a
non-trivial function and could take care of process output itself. Thus,
accept-process-output will wait for nonexistent output, and stall
emacs. The patch just reverts the order in the (and ...) above.

    Thanks, 
    Vitalie

[0001-Avoid-hanging-emacs-by-complex-comint-input-senders.patch (text/x-diff, inline)]

From d3c2753a571688370a4bc8fa2254679d9c23b74a Mon Sep 17 00:00:00 2001
From: Vitalie Spinu <spinuvit <at> gmail.com>
Date: Thu, 27 Dec 2012 21:46:38 +0100
Subject: [PATCH] Avoid hanging emacs by complex comint input senders.

Revert the order of echo-len check and accept-process-output to avoid stalling
Emacs when there is no process output left.
---
 lisp/ChangeLog |    6 ++++++
 lisp/comint.el |    4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 5f4853d..cc94b0d 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,9 @@
+2012-12-27  Vitalie Spinu  <spinuvit <at> gmail.com>
+
+	* comint.el (comint-send-input): revert the order of echo-len
+	check and accept-process-output to avoid hanging Emacs when there
+	is no process output left.
+
 2012-12-27  Michael Albinus  <michael.albinus <at> gmx.de>
 
 	* net/tramp.el (tramp-handle-file-accessible-directory-p): New defun.
diff --git a/lisp/comint.el b/lisp/comint.el
index f3450e3..6477f00 100644
--- a/lisp/comint.el
+++ b/lisp/comint.el
@@ -1847,9 +1847,9 @@ Similarly for Soar, Scheme, etc."
           (let ((echo-len (- comint-last-input-end
                              comint-last-input-start)))
             ;; Wait for all input to be echoed:
-            (while (and (accept-process-output proc)
-                        (> (+ comint-last-input-end echo-len)
+            (while (and (> (+ comint-last-input-end echo-len)
                            (point-max))
+                        (accept-process-output proc)
                         (zerop
                          (compare-buffer-substrings
                           nil comint-last-input-start
-- 
1.7.10.4

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

In GNU Emacs 24.2.91.1 (i686-pc-linux-gnu, GTK+ Version 2.24.13)
 of 2012-12-25 on vitoshka-home
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Ubuntu 12.10

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

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

From: Glenn Morris <rgm <at> gnu.org>
To: Vitalie Spinu <spinuvit <at> gmail.com>
Cc: 13290 <at> debbugs.gnu.org
Subject: Re: bug#13290: 24.2.91;
	[PATCH] Comint can stall emacs with non-trivial input senders
Date: Thu, 03 Jan 2013 01:49:03 -0500

Vitalie Spinu wrote:

> The problem is that, occasionally, comint-input-sender might be a
> non-trivial function and could take care of process output itself.

Thanks for the report. Could you give an example of this happening in
practice?

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

From: Vitalie Spinu <spinuvit <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13290 <at> debbugs.gnu.org
Subject: Re: bug#13290: 24.2.91;
	[PATCH] Comint can stall emacs with non-trivial input senders
Date: Thu, 03 Jan 2013 11:47:44 +0100

  >> Glenn Morris <rgm <at> gnu.org>
  >> on Thu, 03 Jan 2013 01:49:03 -0500 wrote:

  > Vitalie Spinu wrote:
  >> The problem is that, occasionally, comint-input-sender might be a
  >> non-trivial function and could take care of process output itself.

  > Thanks for the report. Could you give an example of this happening in
  > practice?

Yes,  this was happening in ESS under some specific
conditions. Particularly when the user wants to evaluate the code
linewise, i.e. each line of code is echoed in the comint buffer, and
then the output is immediately inserted after that line.

This is implemented in comint-input-sender function, and it does nothing
else than just send input line by line and wait after each line for the
process output. Thus, after the execution of comint-input-sender there
was no process output left, and comint was waiting for nothing.

Cases like above, when both input and output should be manipulated, are
not easily implemented in comint-preoutput-filter-functions.

    Vitalie

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

From: Vitalie Spinu <spinuvit <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13290 <at> debbugs.gnu.org
Subject: Re: bug#13290: 24.2.91;
	[PATCH] Comint can stall emacs with non-trivial input senders
Date: Sun, 06 Jan 2013 15:55:04 +0100

Would you mind adding this to emacs-24? This one really makes our life
at ESS difficult, and I cannot see a reliable workaround on our side.

Comint tweak, on the other side, is harmless and will preclude similar
problems in the future.  

    Thanks, 
    Vitalie

  >> Vitalie Spinu <spinuvit <at> gmail.com>
  >> on Thu, 03 Jan 2013 11:47:44 +0100 wrote:

  >> Glenn Morris <rgm <at> gnu.org>
  >> on Thu, 03 Jan 2013 01:49:03 -0500 wrote:

  >> Vitalie Spinu wrote:
  >> The problem is that, occasionally, comint-input-sender might be a
  >> non-trivial function and could take care of process output itself.

  >> Thanks for the report. Could you give an example of this happening in
  >> practice?

  VS> Yes,  this was happening in ESS under some specific
  VS> conditions. Particularly when the user wants to evaluate the code
  VS> linewise, i.e. each line of code is echoed in the comint buffer, and
  VS> then the output is immediately inserted after that line.

  VS> This is implemented in comint-input-sender function, and it does nothing
  VS> else than just send input line by line and wait after each line for the
  VS> process output. Thus, after the execution of comint-input-sender there
  VS> was no process output left, and comint was waiting for nothing.


  VS> Cases like above, when both input and output should be manipulated, are
  VS> not easily implemented in comint-preoutput-filter-functions.

  VS>     Vitalie

Message #19 received at 13290-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 13290-done <at> debbugs.gnu.org
Subject: Re: bug#13290: 24.2.91;
	[PATCH] Comint can stall emacs with non-trivial input senders
Date: Sun, 06 Jan 2013 20:07:06 -0500

Version: 24.2.92

OK; applied.

Previous Next

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