GNU bug report logs - #34821
discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Platon Pronko <platon7pronko@HIDDEN>; dated Tue, 12 Mar 2019 08:10:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 34821 <at> debbugs.gnu.org:


Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 19:25:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 07 15:25:48 2019
Received: from localhost ([127.0.0.1]:48725 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hDDQJ-0005Ys-Px
	for submit <at> debbugs.gnu.org; Sun, 07 Apr 2019 15:25:47 -0400
Received: from eggs.gnu.org ([209.51.188.92]:40378)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hDDQH-0005Ye-2O
 for 34821 <at> debbugs.gnu.org; Sun, 07 Apr 2019 15:25:46 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:58869)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hDDQB-0002AI-KO; Sun, 07 Apr 2019 15:25:39 -0400
Received: from [176.228.60.248] (port=3162 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hDDQ7-0008IO-4N; Sun, 07 Apr 2019 15:25:35 -0400
Date: Sun, 07 Apr 2019 22:25:28 +0300
Message-Id: <83ftqt8vo7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Platon Pronko <platon7pronko@HIDDEN>
In-reply-to: <0029f748-36b6-e344-9aef-53f0e2101200@HIDDEN> (message from
 Platon Pronko on Sun, 7 Apr 2019 22:06:23 +0300)
Subject: Re: bug#34821: discard_input_tty does not discard pending input,
 resulting in garbage inserted into the buffer
References: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
 <cdacd65a-bb3c-a51e-d9b9-a96ae516988c@HIDDEN>
 <83v9zp93gq.fsf@HIDDEN>
 <492c723c-6ba9-24da-108f-b25cef0dd54e@HIDDEN>
 <83r2ad8yh1.fsf@HIDDEN> <0029f748-36b6-e344-9aef-53f0e2101200@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 34821
Cc: 34821 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> From: Platon Pronko <platon7pronko@HIDDEN>
> Date: Sun, 7 Apr 2019 22:06:23 +0300
> 
> > What do you mean by "run concurrently"?  Emacs is pretty much a single
> > threaded program, and there's only one Lisp thread running at any
> > given time, which will execute both calls.
> 
> My knowledge of Emacs internals is pretty thin indeed. But since adding sleep-for results in reordering of events, I thought that there are at least different threads that compete for execution (concurrent, maybe not parallel). Also I noticed that for example read_char() calls can block for quite a lot of time, while Lisp code continues to run. Perhaps there is one Lisp thread and some other background C threads?

No, there's just one thread.  The only other one I can think of is the
code of xterm itself.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#34821; Package emacs. Full text available.

Message received at 34821 <at> debbugs.gnu.org:


Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 19:06:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 07 15:06:36 2019
Received: from localhost ([127.0.0.1]:48713 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hDD7k-00052O-Ha
	for submit <at> debbugs.gnu.org; Sun, 07 Apr 2019 15:06:36 -0400
Received: from mail-lf1-f54.google.com ([209.85.167.54]:43509)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <platon7pronko@HIDDEN>) id 1hDD7i-00052B-TN
 for 34821 <at> debbugs.gnu.org; Sun, 07 Apr 2019 15:06:35 -0400
Received: by mail-lf1-f54.google.com with SMTP id g7so7799441lfh.10
 for <34821 <at> debbugs.gnu.org>; Sun, 07 Apr 2019 12:06:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=subject:to:references:from:message-id:date:user-agent:mime-version
 :in-reply-to:content-transfer-encoding:content-language;
 bh=5KaOg8/b8Xu5tKM+/HrbKN5zZ5l32j8ezfeiEqXJ4WQ=;
 b=eJlGQCT4PqznscI7Kmk20DjeQ9bP7f3TYDGdpsQSLdRigIkckmRlwrstkMku4y9oUw
 LngcWy9bW425cmWTJSEzp8q72+hM+w+Fqtzis3PuZ34OC2MuRxk56SUirgN+P1gmJMp1
 YWiW0+M4LI7LR/Bl1EhfYmh8gtFckV3x1/LI8miDSkkuYO/XIW1v/9Wjr/bNY+Qua4/L
 Ng3yN8s2VTWKvRVw5XO8WJCN5pbRVnUoKRv2wppY4OaPCMlZfWQnVyx7Yw5HpF7M5ri8
 Q9Ue2IdOaj5YKo5atvg+8NfOPlAdsggDtGBxX5vMfT/z6TCh8TEhy5xDMEEmKVRsrMcK
 yrQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:to:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-transfer-encoding
 :content-language;
 bh=5KaOg8/b8Xu5tKM+/HrbKN5zZ5l32j8ezfeiEqXJ4WQ=;
 b=mINHGlXEUfliVYgbiGvIsphveRsGJSJLKT9oR0VRQOjinrOR+fYyemay+5L0aiOy5+
 FYxZInj0qL7sySNxpAiS0vxJoDdFoGsqjShYz40j78469rsGkUTsYpktGbq9jA8mxIfv
 f4NL39/wF3LtY9fqzLotpgBbSCvqjaPxwQ06xfZ4HFaglmPErwnZXCw9/PZeAYRDyXYy
 t7JsLt5sBBcTrN7pYRtHSrkF1EBfyF+FgFOy3EN1Wm03Sfu4ia4rWJv4W5S6KpYKeqpN
 HHn5BdE+AOVDL3Nh0w53UVKZyjzF2XAbaeGxlPG66cN4HSFWMWOXYYAuZG7xkU//eFCr
 uhPA==
X-Gm-Message-State: APjAAAVlbRK5BXJkZdCHwiU8BBqoT0Py77CP3aXBlcLl3cD8wycnrgBp
 0OrNPaltio7MLUgOB9CfuF4NC8Kc
X-Google-Smtp-Source: APXvYqyhh7eNQLi2rCf/MM9JEGsjgvqAsK5BRpwPlzau1vynyUz8r2XWtV9J4BBNTdCcvgMytz/wkw==
X-Received: by 2002:ac2:4850:: with SMTP id 16mr4356090lfy.70.1554663988136;
 Sun, 07 Apr 2019 12:06:28 -0700 (PDT)
Received: from [192.168.1.65] (109-252-80-126.nat.spd-mgts.ru.
 [109.252.80.126])
 by smtp.gmail.com with ESMTPSA id u19sm5634638lfg.74.2019.04.07.12.06.26
 for <34821 <at> debbugs.gnu.org>
 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128);
 Sun, 07 Apr 2019 12:06:26 -0700 (PDT)
Subject: Re: bug#34821: discard_input_tty does not discard pending input,
 resulting in garbage inserted into the buffer
To: 34821 <at> debbugs.gnu.org
References: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
 <cdacd65a-bb3c-a51e-d9b9-a96ae516988c@HIDDEN> <83v9zp93gq.fsf@HIDDEN>
 <492c723c-6ba9-24da-108f-b25cef0dd54e@HIDDEN> <83r2ad8yh1.fsf@HIDDEN>
From: Platon Pronko <platon7pronko@HIDDEN>
Message-ID: <0029f748-36b6-e344-9aef-53f0e2101200@HIDDEN>
Date: Sun, 7 Apr 2019 22:06:23 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <83r2ad8yh1.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  > What do you mean by "run concurrently"? Emacs is pretty
 much a single > threaded program, and there's only one Lisp thread running
 at any > given time, which will execute both calls. My knowledge of Emacs
 internals is pretty thin indeed. But since adding sleep-for results in
 reordering
 of events, I thought that there are at least different threads that compete
 for execution (concu [...] 
 Content analysis details:   (1.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (platon7pronko[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
 [109.252.80.126 listed in dnsbl.sorbs.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.167.54 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 34821
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

> What do you mean by "run concurrently"?  Emacs is pretty much a single
> threaded program, and there's only one Lisp thread running at any
> given time, which will execute both calls.

My knowledge of Emacs internals is pretty thin indeed. But since adding sleep-for results in reordering of events, I thought that there are at least different threads that compete for execution (concurrent, maybe not parallel). Also I noticed that for example read_char() calls can block for quite a lot of time, while Lisp code continues to run. Perhaps there is one Lisp thread and some other background C threads?

> You may be right, but my reasoning was that without knowing why
> there's a second buffer-switch event sometimes, we will be unable to
> devise a good solution.  IOW, I think we need to understand the issue
> better before we are ready to discuss a solution.
I agree. I'll look at what causes that second event, I'm quite interested in the mechanics of it anyway.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#34821; Package emacs. Full text available.

Message received at 34821 <at> debbugs.gnu.org:


Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 18:25:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 07 14:25:16 2019
Received: from localhost ([127.0.0.1]:48683 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hDCTk-0001zx-72
	for submit <at> debbugs.gnu.org; Sun, 07 Apr 2019 14:25:16 -0400
Received: from eggs.gnu.org ([209.51.188.92]:58260)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hDCTi-0001zj-Cl
 for 34821 <at> debbugs.gnu.org; Sun, 07 Apr 2019 14:25:14 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:57832)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hDCTb-00075E-4n; Sun, 07 Apr 2019 14:25:08 -0400
Received: from [176.228.60.248] (port=3422 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hDCTY-0007wr-SB; Sun, 07 Apr 2019 14:25:06 -0400
Date: Sun, 07 Apr 2019 21:24:58 +0300
Message-Id: <83r2ad8yh1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Platon Pronko <platon7pronko@HIDDEN>
In-reply-to: <492c723c-6ba9-24da-108f-b25cef0dd54e@HIDDEN> (message from
 Platon Pronko on Sun, 7 Apr 2019 20:14:21 +0300)
Subject: Re: bug#34821: discard_input_tty does not discard pending input,
 resulting in garbage inserted into the buffer
References: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
 <cdacd65a-bb3c-a51e-d9b9-a96ae516988c@HIDDEN>
 <83v9zp93gq.fsf@HIDDEN> <492c723c-6ba9-24da-108f-b25cef0dd54e@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 34821
Cc: 34821 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> From: Platon Pronko <platon7pronko@HIDDEN>
> Date: Sun, 7 Apr 2019 20:14:21 +0300
> 
> I guess that something in (terminal-init-xterm) hooks results in some buffer switch event being fired, that triggers the second return from read_char(). But since (terminal-init-xterm) and read_key_sequence() run concurrently, we have a race condition - if the terminal responds quickly enough, second buffer switch does not trigger quick enough and this problem happens.

What do you mean by "run concurrently"?  Emacs is pretty much a single
threaded program, and there's only one Lisp thread running at any
given time, which will execute both calls.

> Maybe trying to rely on terminal being slow with the response is not the best solution? Even if I find a cause of the buffer switch event, we won't have a way to ensure that it always arrives before the response to SDA query (because multithreading).

You may be right, but my reasoning was that without knowing why
there's a second buffer-switch event sometimes, we will be unable to
devise a good solution.  IOW, I think we need to understand the issue
better before we are ready to discuss a solution.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#34821; Package emacs. Full text available.

Message received at 34821 <at> debbugs.gnu.org:


Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 17:14:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 07 13:14:33 2019
Received: from localhost ([127.0.0.1]:48658 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hDBNJ-0000J7-Bu
	for submit <at> debbugs.gnu.org; Sun, 07 Apr 2019 13:14:33 -0400
Received: from mail-lf1-f65.google.com ([209.85.167.65]:41753)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <platon7pronko@HIDDEN>) id 1hDBNH-0000Is-AO
 for 34821 <at> debbugs.gnu.org; Sun, 07 Apr 2019 13:14:32 -0400
Received: by mail-lf1-f65.google.com with SMTP id 10so7705184lfr.8
 for <34821 <at> debbugs.gnu.org>; Sun, 07 Apr 2019 10:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=subject:to:references:from:message-id:date:user-agent:mime-version
 :in-reply-to:content-transfer-encoding:content-language;
 bh=5Mw5MJxDhneoHs5xtlkiSwOiiZPYMuo3s7B5LDCGfZo=;
 b=RrF1pVulwbgxUASZ7p6u9VPPp9CbBmBi11BWKlfCJnE0uAN0p/ljYyZrrNB1lBed+d
 +OzsJr2JTAz3pYbtfuzlvcLQR8mcK69Iso/dV31QMAb8PQIlUyGraKSbY6qHfeh1aTbM
 kfAP/WbVzneHDUxwMXKxbp7JaBG6gKCKDN7m0LreN0P95rEr4SgADgvXf62QU8HUgr/2
 qzOES/Y+ER+X2nUiNtfoPMB5MQj7M81uVs5DQho5ZHfyJtikqSbk4oFlyRAheI/3zm4S
 nfPrl8hKctWag8n15DO1l3d/c8Uur/mBGa8V2QCmZ3OqvVVlHP/BA+YoSkTCZlJp3bXE
 mDNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:to:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-transfer-encoding
 :content-language;
 bh=5Mw5MJxDhneoHs5xtlkiSwOiiZPYMuo3s7B5LDCGfZo=;
 b=i273vOHdYyJBV0EViSZ4qV7Xmy9ZRCsHEwmAchwlt59Ucvr/dmXadM6CMYvy+84sFl
 9qz17VeA872LYEcO4TwsWcr9ClvYXV3rYdl88+fiDUgWRmZMJXBoDSxgj8F6L3OmCnzI
 d+yt8UFj+mUVQx4XRPQjiXtYM94v1tcAiczhbQP1fS1FOtCDQ8mN2sPgfvBiitu68Aml
 nWMomBfYFBpGxnW5vaoXHi2tctmiTjOtpqhcNC1i3sY1qGaQ+cFEOyeSHzj4jqgxCug7
 j82ih2ZMjuLtZCpXhzqTVJmxAUJAxADILTEKDFCZnh7s45M1MER7JYc99gSp9eyWNJTk
 JC8w==
X-Gm-Message-State: APjAAAWMvsG2K3vWJ3PV8kGCg52ekM1va+40o/lnRykobdyYpbqDN9Ek
 LuLmIbtv6WCxB+QfD2bHnVHWFOWk
X-Google-Smtp-Source: APXvYqxLzO+3hvnZAisJxuQEqglJ7TnO7XPWkHKIrYC6mhH9f1mxu+kmPQlUc2N2vBitjWNS8dh9TQ==
X-Received: by 2002:ac2:4421:: with SMTP id w1mr13349627lfl.97.1554657264886; 
 Sun, 07 Apr 2019 10:14:24 -0700 (PDT)
Received: from [192.168.1.65] (109-252-80-126.nat.spd-mgts.ru.
 [109.252.80.126])
 by smtp.gmail.com with ESMTPSA id i66sm5881781lji.43.2019.04.07.10.14.23
 for <34821 <at> debbugs.gnu.org>
 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128);
 Sun, 07 Apr 2019 10:14:24 -0700 (PDT)
Subject: Re: bug#34821: discard_input_tty does not discard pending input,
 resulting in garbage inserted into the buffer
To: 34821 <at> debbugs.gnu.org
References: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
 <cdacd65a-bb3c-a51e-d9b9-a96ae516988c@HIDDEN> <83v9zp93gq.fsf@HIDDEN>
From: Platon Pronko <platon7pronko@HIDDEN>
Message-ID: <492c723c-6ba9-24da-108f-b25cef0dd54e@HIDDEN>
Date: Sun, 7 Apr 2019 20:14:21 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <83v9zp93gq.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: I guess that something in (terminal-init-xterm) hooks results
 in some buffer switch event being fired, that triggers the second return
 from read_char(). But since (terminal-init-xterm) and read_key_se [...] 
 Content analysis details:   (1.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.167.65 listed in list.dnswl.org]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (platon7pronko[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
 [109.252.80.126 listed in dnsbl.sorbs.net]
 -0.3 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.167.65 listed in wl.mailspike.net]
X-Debbugs-Envelope-To: 34821
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

I guess that something in (terminal-init-xterm) hooks results in some buffer switch event being fired, that triggers the second return from read_char(). But since (terminal-init-xterm) and read_key_sequence() run concurrently, we have a race condition - if the terminal responds quickly enough, second buffer switch does not trigger quick enough and this problem happens.

I verified this by adding (sleep-for 0.1) to (defun xterm--query) or (defun terminal-init-xterm) - this resulted in 100% reproduction of the bug (thanks for the directions, by the way - my hands already hurt after trying to trigger that 1-in-10 bug so many times).

Maybe trying to rely on terminal being slow with the response is not the best solution? Even if I find a cause of the buffer switch event, we won't have a way to ensure that it always arrives before the response to SDA query (because multithreading).





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#34821; Package emacs. Full text available.

Message received at 34821 <at> debbugs.gnu.org:


Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 16:37:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 07 12:37:27 2019
Received: from localhost ([127.0.0.1]:48643 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hDAnO-0007sE-ML
	for submit <at> debbugs.gnu.org; Sun, 07 Apr 2019 12:37:26 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41398)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hDAnL-0007s2-Ap
 for 34821 <at> debbugs.gnu.org; Sun, 07 Apr 2019 12:37:23 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:56759)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hDAnG-0002on-3l; Sun, 07 Apr 2019 12:37:18 -0400
Received: from [176.228.60.248] (port=4396 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hDAnF-0006ZT-3A; Sun, 07 Apr 2019 12:37:17 -0400
Date: Sun, 07 Apr 2019 19:37:09 +0300
Message-Id: <83v9zp93gq.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Platon Pronko <platon7pronko@HIDDEN>
In-reply-to: <cdacd65a-bb3c-a51e-d9b9-a96ae516988c@HIDDEN> (message from
 Platon Pronko on Sun, 7 Apr 2019 19:06:52 +0300)
Subject: Re: bug#34821: discard_input_tty does not discard pending input,
 resulting in garbage inserted into the buffer
References: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
 <cdacd65a-bb3c-a51e-d9b9-a96ae516988c@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 34821
Cc: 34821 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> From: Platon Pronko <platon7pronko@HIDDEN>
> Date: Sun, 7 Apr 2019 19:06:52 +0300
> 
> Can somebody please advise me about the right course of action in this case? Should I figure out a way to load Vinput_decode_map when new character arrives and `interrupted_kboard != current_kboard`? Or should I look into why read_char() does not return a buffer the second time?

The latter, I think.  But I'm far from being an expert on this, so
caveat emptor.

Thanks for looking into this tricky problem.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#34821; Package emacs. Full text available.

Message received at 34821 <at> debbugs.gnu.org:


Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 16:07:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 07 12:07:04 2019
Received: from localhost ([127.0.0.1]:48615 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hDAJz-00077h-WB
	for submit <at> debbugs.gnu.org; Sun, 07 Apr 2019 12:07:04 -0400
Received: from mail-lj1-f172.google.com ([209.85.208.172]:42422)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <platon7pronko@HIDDEN>) id 1hDAJx-00077C-2G
 for 34821 <at> debbugs.gnu.org; Sun, 07 Apr 2019 12:07:01 -0400
Received: by mail-lj1-f172.google.com with SMTP id v22so9058268lje.9
 for <34821 <at> debbugs.gnu.org>; Sun, 07 Apr 2019 09:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:subject:to:references:message-id:date:user-agent:mime-version
 :in-reply-to:content-transfer-encoding:content-language;
 bh=36TTsJpKmHVZ1K4Kq8oIMo8bEQyq9UMECgGxuKSq+rw=;
 b=PR+d3HkcLY6IHf96SFVXy44w+Q0NVEB9XqkYLVpLkmRdUZAjjz3V8n5tmbKdox/aGW
 wsZu3ZdJs4VSnZVcEQRx4nRnqs/JFT64weVSVzgjR/qKV36XxL14rGaV8v5/1cPHyj3s
 e34+jBSeVGZ6qzxHKhoQZ8R+AgVLST8Dukl0m15/mzZ+tIyaIqEqMBk6VSb1cpGgAjbE
 L9OkUNNvNwfa90n10XpCocS6gFq/FciyMHPlPLQEvjxDpQt0qFkZVSdlmVHkpdG7QkIf
 jSiNtvNErxoHs1s1yDhI4sXrCDO8SZPvQS2ZUuZNzjaDl7DgeH2SFr5orU51urvFfKLP
 GDhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:subject:to:references:message-id:date
 :user-agent:mime-version:in-reply-to:content-transfer-encoding
 :content-language;
 bh=36TTsJpKmHVZ1K4Kq8oIMo8bEQyq9UMECgGxuKSq+rw=;
 b=ukKlSPxJCmODlZvE2OLgvg/Vxysf9gmG8p+td1Z9vg8u5dCJBaAelA752ySb9a5zK9
 O4S711ArGTX1e15OKF3FHdiA0/Oc+7CQpoI3Op+gfpNLeT6X57n8xbCzmtpchP57wevX
 p8oOzWzDww7xJmKYpDXkz3zfaoZgdoU9tOOywc3AFICClcBsWDJG9J/kd9LSAZAYURwj
 b931tVVV2REIFwsxdWVlEm9JiekrjdSPhciMa6pVihODtQww+OXXGnXWKUEJ2JMtwSxH
 tFWBuCKsSDH3sg3EPZk/qhQzZ3YECKqFRUpySHcY1MCQI/nuJpUSOQH6uMEzfTRxgeBH
 dTZQ==
X-Gm-Message-State: APjAAAUkp95rLRZTI8+bd+KW3e9Qj6J9aMrQfnXnEnkADgp0YPRc2fOq
 pX7nuN9MtnZrWLBoO0NEyIkTzaHv
X-Google-Smtp-Source: APXvYqx1Vb0ycH11KdDqs8Qvn+1SGZqmeqSLNrzTf/wf+y29vlkg8usp2FenSoH52cjAMnCDzkVn8w==
X-Received: by 2002:a2e:3803:: with SMTP id f3mr13778692lja.165.1554653214747; 
 Sun, 07 Apr 2019 09:06:54 -0700 (PDT)
Received: from [192.168.1.65] (109-252-80-126.nat.spd-mgts.ru.
 [109.252.80.126])
 by smtp.gmail.com with ESMTPSA id z13sm5798771ljk.41.2019.04.07.09.06.53
 for <34821 <at> debbugs.gnu.org>
 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128);
 Sun, 07 Apr 2019 09:06:53 -0700 (PDT)
From: Platon Pronko <platon7pronko@HIDDEN>
Subject: Re: discard_input_tty does not discard pending input, resulting in
 garbage inserted into the buffer
To: 34821 <at> debbugs.gnu.org
References: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
Message-ID: <cdacd65a-bb3c-a51e-d9b9-a96ae516988c@HIDDEN>
Date: Sun, 7 Apr 2019 19:06:52 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  I decided to go with async approach, since it is the one that
 is at least theoretically fool-proof. Currently I am trying to debug the
 problem of "[>65;5600;1c" appearing sporadically (10%) of the tim [...] 
 Content analysis details:   (1.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
 [109.252.80.126 listed in dnsbl.sorbs.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.208.172 listed in list.dnswl.org]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (platon7pronko[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
X-Debbugs-Envelope-To: 34821
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

I decided to go with async approach, since it is the one that is at least theoretically fool-proof. Currently I am trying to debug the problem of "[>65;5600;1c" appearing sporadically (10%) of the times in the input buffer. The test case is below:

1. Start the daemon and set it to use async term query:
$ ./src/emacs -Q --fg-daemon --eval "(setq xterm-query-timeout nil)"

2. Launch emacsclient:
$ ./lib-src/emacsclient -t /tmp/test.txt

3. About 1 in 10 times, observe "[>65;5600;1c" appearing in the buffer.


I tracked the problem to src/keyboard.c:read_key_sequence() function. In normal case, the following happens:

1. read_ke_sequence() is called for the first time.
2. Current input_decode_map is copied:

indec.map =  indec.map = indec.parent = KVAR (current_kboard, Vinput_decode_map);

3. It calls read_char() and blocks.
4. When emacsclient is invoked, read_char() returns the "buffer" object as per this comment:

/* When switching to a new tty (with a new keyboard),
   read_char returns the new buffer, rather than -2
   (Bug#5095).  This is because `terminal-init-xterm'
   calls read-char, which eats the wrong_kboard_jmpbuf
   return.  Any better way to fix this? -- cyd */

5. `interrupted_kboard != current_kboard` condition is triggered, this read_char() result is discarded and we jump to replay_entire_sequence.
6. read_char() is called again.
7. (terminal-init-xterm) function is invoked.
8. (xterm-query) registeres a handlers for "\e[?" and "\e[>" escape sequences.
9. read_char() returns the "buffer" object the second time.
10. That read_char() result triggers `interrupted_kboard != current_kboard` condition again, and we jump to replay_entire_sequence again.
11. Immediately after that jump, we reset the input map: `indec.map =  indec.map = indec.parent = KVAR (current_kboard, Vinput_decode_map);`, thus pulling in handlers from step 8.
12. The subsequent read_char() calls return the next SDA response characters, match is found in indec.map and xterm--verision-handler is executed.


For a situation when bug manifests steps 1-8 are the same, however at step 9 the difference happens - read_char() does not return a buffer, instead it returns the first character of the response (0x1b). `interrupted_kboard != current_kboard` is still true at that moment, thus this character is discarded. Subsequent SDA response characters (0x5b, 0x3e) fail to find a prefix match in input_decode_map, and are inserted into the buffer as-is.

I tried changing condition `interrupted_kboard != current_kboard` to `interrupted_kboard != current_kboard && BUFFERP(key)`, but that does not trigger `goto replay_entire_sequence` and thus new handlers are not pulled in from Vinput_decode_map, and so the characters are still inserted into the buffer.

Can somebody please advise me about the right course of action in this case? Should I figure out a way to load Vinput_decode_map when new character arrives and `interrupted_kboard != current_kboard`? Or should I look into why read_char() does not return a buffer the second time?






Information forwarded to bug-gnu-emacs@HIDDEN:
bug#34821; Package emacs. Full text available.

Message received at 34821 <at> debbugs.gnu.org:


Received: (at 34821) by debbugs.gnu.org; 13 Mar 2019 08:04:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 13 04:04:39 2019
Received: from localhost ([127.0.0.1]:40995 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1h3ysR-0006hT-32
	for submit <at> debbugs.gnu.org; Wed, 13 Mar 2019 04:04:39 -0400
Received: from mail-lj1-f170.google.com ([209.85.208.170]:42178)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <platon7pronko@HIDDEN>) id 1h3ysO-0006hF-Dn
 for 34821 <at> debbugs.gnu.org; Wed, 13 Mar 2019 04:04:37 -0400
Received: by mail-lj1-f170.google.com with SMTP id v3so662143ljk.9
 for <34821 <at> debbugs.gnu.org>; Wed, 13 Mar 2019 01:04:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=subject:from:to:references:message-id:date:user-agent:mime-version
 :in-reply-to:content-transfer-encoding:content-language;
 bh=8zkWjz2TsXGZmtJYRcm0jhfklydHeHcNMPH7hUMdc1o=;
 b=ZYPLsZFQEKAhME7wqZLDoWF7DSaet/49clQ5OZgcHRnW/uS5aDOjJGI1oFVHDMN0aE
 jMGViuAtAWo2VGsVUZFfF9vOBabBSIOL/sTosGIP30ErKAOMT79RoZZIhWMQff6HB8i9
 7HuMVpBOEpFjMQuQtzz7W5Ikq3P19Gq0ZY1rvxzdIckoSflkfp7e9LllMsdGpYPEp/DP
 5OrESXmqVmTM72dUNvcAY3XH3T6dGbeifZOWbVABX/CiPVitFhceoFyrBmj3LQkycqLh
 xc4gO+mN4CVvF9GUPzGGVnFKLWVpvboTzLFK3xc7GMvLq9XQyTyHN+hDMTt61TpxTWVn
 vzag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:from:to:references:message-id:date
 :user-agent:mime-version:in-reply-to:content-transfer-encoding
 :content-language;
 bh=8zkWjz2TsXGZmtJYRcm0jhfklydHeHcNMPH7hUMdc1o=;
 b=I0DmVY14ermRqL7fl+gJdpOJickEHbT3M0C7bxCvU4lkdnPxgicML6nR/Uyka8bAvJ
 hV8gZzZsS996BfEhyZm1JqVsmQZKqH+a65TtYp9HyfkcLiD3CnzWiZX6irFgRt0FS9yR
 z+czEJ87yAQyDCx86OZdQWyoI6DlSJFMt+rD3cjQAy2hJ4gIeftrREkH9Qjsmwj280LS
 6G1j4vJdbtYRr4W9GdBgmtkRvKwweiVroEuyaZ/RY8ri4DGTDopsBRnhpO+n1FS53wQU
 vLqrQADq5oC+RVaMoewYpap56RhXPWUGlpXPPxnlLzQ19R6FukFWH6XlaVniebY/AbkI
 AJqA==
X-Gm-Message-State: APjAAAVGFSHvGwtMPjbduWPuuZ/oEh96SR0hquv3zU+ibTI7YE3I/6Yi
 werwXxm8fQfy4HZa0Ni4H/XaZNEE
X-Google-Smtp-Source: APXvYqyk2A47vul+0MgsU7WrY4eoTDVpktRovH8zDNvLQSPRMt9Feo+v5B+K7Lmnb0GWAPSZ+NJU/g==
X-Received: by 2002:a2e:9607:: with SMTP id v7mr15536062ljh.154.1552464270074; 
 Wed, 13 Mar 2019 01:04:30 -0700 (PDT)
Received: from [192.168.1.65] (109-252-80-126.nat.spd-mgts.ru.
 [109.252.80.126])
 by smtp.gmail.com with ESMTPSA id m16sm1680622ljb.50.2019.03.13.01.04.28
 for <34821 <at> debbugs.gnu.org>
 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128);
 Wed, 13 Mar 2019 01:04:29 -0700 (PDT)
Subject: Re: discard_input_tty does not discard pending input, resulting in
 garbage inserted into the buffer
From: Platon Pronko <platon7pronko@HIDDEN>
To: 34821 <at> debbugs.gnu.org
References: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
Message-ID: <66917314-4c95-f2e3-1faa-49154772e197@HIDDEN>
Date: Wed, 13 Mar 2019 11:04:28 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Found two problems with current workarounds. 1. Simply
 reading
 and discarding events before xterm--query call still leaves small timing
 window while single typed character breaks response parsing and garbage still
 ends up in the buffer. 
 Content analysis details:   (1.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.208.170 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (platon7pronko[at]gmail.com)
 1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
 [109.252.80.126 listed in dnsbl.sorbs.net]
X-Debbugs-Envelope-To: 34821
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

Found two problems with current workarounds.

1. Simply reading and discarding events before xterm--query call still leaves small timing window while single typed character breaks response parsing and garbage still ends up in the buffer.

2. Thus async querying is prefererrable, and it works most of the time, but sometimes "65;5403;1c" ends up in input buffer (even if no characters are typed at all).





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#34821; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 12 Mar 2019 08:09:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 12 04:09:48 2019
Received: from localhost ([127.0.0.1]:39743 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1h3cTs-0004db-Fq
	for submit <at> debbugs.gnu.org; Tue, 12 Mar 2019 04:09:48 -0400
Received: from eggs.gnu.org ([209.51.188.92]:53652)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <platon7pronko@HIDDEN>) id 1h3cTq-0004dO-LV
 for submit <at> debbugs.gnu.org; Tue, 12 Mar 2019 04:09:47 -0400
Received: from lists.gnu.org ([209.51.188.17]:39110)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <platon7pronko@HIDDEN>)
 id 1h3cTl-0006mJ-AZ
 for submit <at> debbugs.gnu.org; Tue, 12 Mar 2019 04:09:41 -0400
Received: from eggs.gnu.org ([209.51.188.92]:39421)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <platon7pronko@HIDDEN>) id 1h3cTj-0006j4-Rf
 for bug-gnu-emacs@HIDDEN; Tue, 12 Mar 2019 04:09:41 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: **
X-Spam-Status: No, score=2.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
 RCVD_IN_SORBS_WEB autolearn=disabled version=3.3.2
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <platon7pronko@HIDDEN>) id 1h3cEA-0002wI-3v
 for bug-gnu-emacs@HIDDEN; Tue, 12 Mar 2019 03:53:35 -0400
Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]:35553)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.71) (envelope-from <platon7pronko@HIDDEN>)
 id 1h3cE9-0002vI-JZ
 for bug-gnu-emacs@HIDDEN; Tue, 12 Mar 2019 03:53:33 -0400
Received: by mail-lf1-x141.google.com with SMTP id h6so1309400lfc.2
 for <bug-gnu-emacs@HIDDEN>; Tue, 12 Mar 2019 00:53:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=to:from:subject:message-id:date:user-agent:mime-version
 :content-language;
 bh=Kwug2zGxYtX2UQLAbzyLK9fpQ0KWwh4t1DU9NPGGnlA=;
 b=pMx5z2yZtcbRwW0ILwgR2iDDVT1chW2p6C043KRfuSp2GmjH3ef5BG6j1UqUgSDHqq
 AfrMljQpBb2Egk/YUCxIWnDAZcAAUM+tZCv336sHO7A1A3HaDXTsxoqLfiq0eB0L6H7I
 H3GFBUKTOfRgXi1HefaaywG7XjIEO2wOm83PhwuuUo1NwQd7c8kLfDcyMqQ/mtPPzaiT
 DvXQIamFhcgsvmdDi/7ZWlrzNHjcZhpBFJxmkz9o36vufRDQSIHljPOH/wrwRPilNUwO
 l7cdFU3EW0q5beRxnmGlGo7K+QnDn/iJEuaN0eH99T9LJpmsd824D3D0Kip881S+JbNu
 bmAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:to:from:subject:message-id:date:user-agent
 :mime-version:content-language;
 bh=Kwug2zGxYtX2UQLAbzyLK9fpQ0KWwh4t1DU9NPGGnlA=;
 b=CRSae7DxuFVMgyIGe2/IUVmtjbAxcBhLaPut/wXpvJ0+PrJlMwznB90bTnGxPQox3m
 6/VWL1BkdjPE7ICXIPaViTDFs9sIYL+8EtN+Mj9AadN69yCq6gBIJQMlgvoqyt5IMVEp
 Bc4klhh/OvrKDk1EuzVpM3+4Gb6zxfjCXuCyQGY/M6TQLPERSqQN+i5f7Gi8GwB7sHz1
 ngJxkWnIv2rSvV86ap7IAUhMj1d6qJN4GgHTMsxiu0B182TrpTjSKhF83DAi9JQUjz+O
 4T5kbublIENr15Nr+x/7Ufmod8V0eOF+oS9PCK3hwjhVnB8GaANpT8OWQ1vCEjAT7rBg
 oolQ==
X-Gm-Message-State: APjAAAXVOaYSUkLMBPhRHhtc3+d6w6nmJ2E5JIfBJXhrUVoHgwv7n41L
 NvRoyh9DXB9qTYgJ3M5QavvNYf6T
X-Google-Smtp-Source: APXvYqxuLJWWd5EscdQXEWDvo8TrFQXCWzp4K34cz/V1PR8S2RuLOBTUso9depObF+OpZvVMFVtAiQ==
X-Received: by 2002:a19:ec17:: with SMTP id b23mr10601803lfa.76.1552377211461; 
 Tue, 12 Mar 2019 00:53:31 -0700 (PDT)
Received: from [192.168.1.65] ([109.252.80.126])
 by smtp.gmail.com with ESMTPSA id q22sm1232920ljc.59.2019.03.12.00.53.30
 for <bug-gnu-emacs@HIDDEN>
 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128);
 Tue, 12 Mar 2019 00:53:30 -0700 (PDT)
To: bug-gnu-emacs@HIDDEN
From: Platon Pronko <platon7pronko@HIDDEN>
Subject: discard_input_tty does not discard pending input, resulting in
 garbage inserted into the buffer
Message-ID: <6e2317c9-5063-3718-740e-f53c70f5db5b@HIDDEN>
Date: Tue, 12 Mar 2019 10:53:29 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------0646CE0A69D45F1D55B1CA10"
Content-Language: en-US
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-Received-From: 2a00:1450:4864:20::141
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hi! Steps to reproduce: 1. Add dummy autosave file (needed
 for additional delay when starting and reliable bug reproduction): $ touch
 /tmp/#test.txt# 
 Content analysis details:   (2.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
 [109.252.80.126 listed in dnsbl.sorbs.net]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (platon7pronko[at]gmail.com)
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hi! Steps to reproduce: 1. Add dummy autosave file (needed
    for additional delay when starting and reliable bug reproduction): $ touch
    /tmp/#test.txt# 
 
 Content analysis details:   (1.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
                             [109.252.80.126 listed in dnsbl.sorbs.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (platon7pronko[at]gmail.com)
  1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

This is a multi-part message in MIME format.
--------------0646CE0A69D45F1D55B1CA10
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi!

Steps to reproduce:

1. Add dummy autosave file (needed for additional delay when starting and reliable bug reproduction):
$ touch /tmp/#test.txt#

2. Launch daemon:
./src/emacs -Q --fg-daemon

3. Start the client:
./lib-src/emacsclient -t /tmp/test.txt

4. type 'a' while emacsclient is starting

5. observe "65;5403;1c" inserted at the start of the new file.

I hunted for the bug and traced it down to terminal-init-xterm and xterm--query. It makes a "Secondary Device Attributes" query, and expects a response with a specific prefix - but if there were characters waiting in input buffer the handler will never see that prefix, and all the bytes will be sent directly to default keyboard handler and inserted into the buffer.

To mitigate the problem xterm--query calls discard-input before sending the query, however for some reason the bytes are still there when read_char is called.

I added a workaround in xterm--query, simple `(while (read-event nil nil 0.01))` (see patch attached). Setting `(setq xterm-query-timeout nil)` switches querying to async mode and also helps (the typed character is not discarded that way, which is even better).

However, I suspect that the real problem lurks in the discard_tty_input, that for some reason does not actually discard the input - but I'm not sure how to debug it.

System details below:

In GNU Emacs 27.0.50 (build 27, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
  of 2019-03-12 built on the-big-maker
Repository revision: d2270d8fc93b5fb0b82fec4d85d122ea4e38dff3
Repository branch: master
System Description: Arch Linux

Recent messages:
Starting Emacs daemon.
test.txt has auto save data; consider M-x recover-this-file
When done with a buffer, type C-x #
Quit
completing-read-default: Command attempted to use minibuffer while in minibuffer

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD JSON PDUMPER
LCMS2 GMP

Important settings:
   value of $LC_TIME: en_SE.UTF-8
   value of $LANG: en_US.UTF-8
   locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
easymenu mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils term/xterm
xterm server elec-pair mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 50376 6377)
  (symbols 48 6051 1)
  (strings 32 15598 1886)
  (string-bytes 1 511783)
  (vectors 16 7797)
  (vector-slots 8 77209 12548)
  (floats 8 28 256)
  (intervals 56 175 0)
  (buffers 992 13))


--------------0646CE0A69D45F1D55B1CA10
Content-Type: text/x-patch;
 name="xterm--query_discard.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xterm--query_discard.patch"

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index c4b0a8fb6e..30919988e9 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -804,6 +804,7 @@ xterm--query
       ;; Pending input can be mistakenly returned by the calls to
       ;; read-event below: discard it.
       (discard-input)
+      (while (read-event nil nil 0.01))
       (send-string-to-terminal query)
       (while handlers
         (let ((handler (pop handlers))

--------------0646CE0A69D45F1D55B1CA10--




Acknowledgement sent to Platon Pronko <platon7pronko@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#34821; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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