Lars Ingebrigtsen <larsi@gnus.org> writes:

> Gemini Lasswell <gazally@runbox.com> writes:
>
>> Lars Ingebrigtsen <larsi@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@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).