GNU bug report logs - #29918
26.0.90; serial-term error in process filter

Previous Next

Full log

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 29918 <at> debbugs.gnu.org, Gemini Lasswell <gazally <at> runbox.com>
Subject: Re: bug#29918: 26.0.90; serial-term error in process filter
Date: Wed, 17 Jul 2019 07:36:34 -0400

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

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Gemini Lasswell <gazally <at> runbox.com> writes:
>
>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>
>>> Does setting (setq debug-on-error t) give you a backtrace for these
>>> errors?
>>
>> No, but I just made one happen by removing the internal_condition_case_1
>> wrapper on the read_process_output_call in read_and_dispose_of_process_output.
>> Then after I got the first backtrace showing that the error was in
>> term-emulate-terminal I eval-defun'd it to make a more useful backtrace:
>>
>> Debugger entered--Lisp error: (args-out-of-range "\376\374\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376" -1)
>>   aref("\376\374\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376\364\376" -1)
>>   (char-charset (aref decoded-substring (- count 1 partial)))
>
> I'm guessing this bug was introduced by:
>
> commit 47019a521f774fbd13441e178a6a82c9989b9912
> Author: Noam Postavsky <npostavs <at> gmail.com>
> Date:   Thu Jan 18 08:22:47 2018 -0500
>
>     Switch term.el to lexical binding, and clean up code a bit

It can't be that patch, because it's only in master, not emacs-26.  I
think it's rather [1: 134e86b360] (also mine).

[1: 134e86b360]: 2017-01-03 08:58:40 -0500
  Handle multibyte chars spanning chunks in term.el
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=134e86b360cab0d0a5cb634b71a4b06ec26c5f1f

If I understand the backtrace correctly, then the problem is that I
didn't think of the case where the whole string fails to decode.  I
think the patch below should fix it; there is a possibility it prevents
correct decoding in case the terminal receives a utf-8 character in
single byte chunks (though I'm not sure if it's even valid for a program
to emit single bytes like that).

[0001-Handle-completely-undecoded-input-in-term-Bug-29918.patch (text/x-diff, inline)]

From 3e2663f8366ea82f52f47019b63fca243e3f88d9 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Wed, 17 Jul 2019 07:20:20 -0400
Subject: [PATCH] Handle completely undecoded input in term (Bug#29918)

* lisp/term.el (term-emulate-terminal): Avoid errors if the whole
decoded string is eight-bit characters.
---
 lisp/term.el | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lisp/term.el b/lisp/term.el
index cbef68dc0a..9785ce3024 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -2900,11 +2900,12 @@ term-emulate-terminal
                           ;; next time.
                           (when (= funny str-length)
                             (let ((partial 0))
-                              (while (eq (char-charset (aref decoded-substring
-                                                             (- count 1 partial)))
-                                         'eight-bit)
+                              (while (and (< partial count)
+                                          (eq (char-charset (aref decoded-substring
+                                                                  (- count 1 partial)))
+                                              'eight-bit))
                                 (cl-incf partial))
-                              (when (> partial 0)
+                              (when (> count partial 0)
                                 (setq term-terminal-undecoded-bytes
                                       (substring decoded-substring (- partial)))
                                 (setq decoded-substring
-- 
2.11.0

Previous Next

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