Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 16:05:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 11:05:41 2025 Received: from localhost ([127.0.0.1]:46620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOy4-00009f-Rp for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:05:41 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:63837) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHOy2-00009X-G2 for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:05:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762531531; x=1762790731; bh=b0CxdY3y0rtheD4de54qywUd0pN93qrd5D5LKtLzOpw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=uZ1ibAmSVal6gqSkgVzu+0bgcJNZxTLcX912NFNwxC4YAxqK7nUJEY597PZ0txZMW q2wxlnFdNQFN+8XE6QUFBYD0D12jNcciscjEEWmTnBB9gNzsBxPzcokJpJXgpVA+Ac 5+XFy3EOeQmM75qoUOdPtp8g7j/297RLao002YqFpDPmIPd8fs04m4WJcd8GnrE+on ucksF/99Vy4zsX2vyaPQX+mnuu9oQHKpOnkrfrdERGBWrgeFC+yFu2UW3sNQOQOr5A 9XeStgqXoIYr3H+HpCq2l1zX5IcpkiinprGXqgTfHfm95nb8VgYviRql2oBRUKnZwH O3jRQ14hu0pkA== Date: Fri, 07 Nov 2025 16:05:25 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <87tsz525hd.fsf@HIDDEN> In-Reply-To: <865xblalac.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e60813f36c098c64f5be3cae948a980e5df667bd MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: Spencer Baugh <sbaugh@HIDDEN>, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@HIDDEN 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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org, >> Paul Eggert <eggert@HIDDEN> >> Date: Fri, 07 Nov 2025 10:18:47 -0500 >> From: Spencer Baugh via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> >> That change looks harmless, but I think it indicates something else = in >> >> the code is incorrect. >> > >> > I think the whole approach of using two select calls is very fragile. >> >> Agreed, I think that's the root of the problem. I have previously found >> other bugs related to this update_tick select call, so I do think it's >> time to just get rid of it. > > It's a non-starter for me, so please don't propose changes that remove > the first call to thread_select. Can you provide a reason for that? The first call clearly seems to be unnecessary and harmful. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 16:03:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 11:03:23 2025 Received: from localhost ([127.0.0.1]:46602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOvr-0008Tf-3H for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:03:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46646) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHOvo-0008TV-Ko for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:03:21 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHOvi-0003At-5n; Fri, 07 Nov 2025 11:03:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Pur2vAiiTlVIWOKHR24T7c1MSZCFMxgf7wt+D7PzUZ4=; b=OB5xeuW0P5+U GSJjFov6qRhNkfk/MLTRW7c+eNwIw6QNfe6jmxQgoNvrtrSWFEKgo7DD9Rd37gvH9zYuMgav/Uv3z DAfAuRviTmFLTUlS49uuYL6VGkM64vzjN0QVghZ9vgyG3oyi5m3B7MFvOww2JuUrVDWhn3ZYP7+Pp sNxsCzR1SOQtTcFzKipnfBNr2y6+c5dhGzlXV5MgXgj+Ku8jq5w58GdcXNJDV56bKKXtlZJOwVcNw 1P0m+Ne9w2EEjB+mz79tNzVzP90dBxtW9m/DK8AJ5tOnPim7cxpZwAhUNdR7QubDNC2slRbuY8S0T /2NBstUfPoIqtHYpZkR6eg==; Date: Fri, 07 Nov 2025 18:03:10 +0200 Message-Id: <86346pakzl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <878qgh3kxh.fsf@HIDDEN> (message from Pip Cet on Fri, 07 Nov 2025 15:46:23 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> <868qghamxf.fsf@HIDDEN> <878qgh3kxh.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@HIDDEN 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: -3.3 (---) > Date: Fri, 07 Nov 2025 15:46:23 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> Date: Fri, 07 Nov 2025 15:00:35 +0000 > >> From: Pip Cet <pipcet@HIDDEN> > >> Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN > >> > >> "Eli Zaretskii" <eliz@HIDDEN> writes: > >> > >> >> We're failing to run status_notify even though process status has > >> >> changed. > >> > > >> > Yes, that's clear. But why do we fail to run status_notify and/or the > >> > sentinel? > >> > >> Whenever we're about to, we discover "input" that should be handled > >> first. > > > > Which input is that? > > "Keyboard" input (actually input on the X socket or equivalent), IIUC. But I didn't press any keys when running the test program. And I also ran it in a -nw session, where no input events should happen except via keyboard keys. So where does keyboard input come from? If this is the root cause of the loop, we must understand how it comes into play.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:56:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:56:53 2025 Received: from localhost ([127.0.0.1]:46556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOpY-0005Sz-Sn for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:56:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57270) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHOpX-0005St-3v for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:56:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHOpR-0006pQ-Eu; Fri, 07 Nov 2025 10:56:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CZ0HIOem/IImav86VLmND4/+HaBnkY/NxrlUGIV43rI=; b=Gs9CFIiAMDer 9u2y86havVganb0y92aBmaybyo6He7NamCd5Hif3rJ+wUVk5TTWjyqPT03WiDqz+nukCBH1XK9km0 rQQc+c4qvzWqJI3Ac0zH/2+RyKzOWQSU7l5mSACyqeqmzNCesMW2lhurrazPsCwUkoUgp1D/0YK47 H5VC0Oe6CPYqUHdoKtMP/CiKlg3dtirZUxVk3STL13TjJNxNHqO94EWr0u96rsHahd2cvn5ZysAC5 XHkuKaFTFdfsSyxrD2b4UwTErpGsK6axdGYR8WLWspl/rQ/tzqWQVNBihJ1hKTs5WRYAHEPzieorG FqRTe0WH4FtH+h3JL+4ZkA==; Date: Fri, 07 Nov 2025 17:56:43 +0200 Message-Id: <865xblalac.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ier346p7two.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: dmitry@HIDDEN, pipcet@HIDDEN, eggert@HIDDEN, 79777 <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: -3.3 (---) > Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org, > Paul Eggert <eggert@HIDDEN> > Date: Fri, 07 Nov 2025 10:18:47 -0500 > From: Spencer Baugh via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > >> That change looks harmless, but I think it indicates something else in > >> the code is incorrect. > > > > I think the whole approach of using two select calls is very fragile. > > Agreed, I think that's the root of the problem. I have previously found > other bugs related to this update_tick select call, so I do think it's > time to just get rid of it. It's a non-starter for me, so please don't propose changes that remove the first call to thread_select.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:46:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:46:45 2025 Received: from localhost ([127.0.0.1]:46454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOfg-00055o-LQ for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:46:44 -0500 Received: from mail-24416.protonmail.ch ([109.224.244.16]:49599) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHOfc-00055b-CC for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:46:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762530389; x=1762789589; bh=zLQNwES8IOVBrEMWLKnic4YohHPCpzvboYMtQIVAQ/c=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hucfcTVpLeJClTAWWcuXerZx6O//A3Nqf9c71gJy5lCFqQBrQa7bSu1Q3xLkOfSdO VrTIFU+zjQXYb+s4uYu9rGhETOyiho51zjETp/P8YwYJ7akm2s5v0bxgus3V6UAaUS 8/iFSVtuU1rzS5+aehPQoBB9TrqYEUiyp9afugS8JdjDMwR7ClIXHUYIhoxR9hA7/f drheCtU8kmtFuthKQWE+DfcY6ifzVEhN2g5bCurB4Pd/d/FzRuyDpfQSIKn89kLQ9I i9Xqnzi9KEhGx/YL5+qX/28kwssCu7sOzNRm57Q7f1pD0GjTv6fjrjiJXa8zbdAmCA j+JpB1gpm/jdw== Date: Fri, 07 Nov 2025 15:46:23 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <878qgh3kxh.fsf@HIDDEN> In-Reply-To: <868qghamxf.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> <868qghamxf.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 9216e7756573b52eb2a5799bd1b4a6ea87ca2a65 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@HIDDEN 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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Fri, 07 Nov 2025 15:00:35 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN= om, dmitry@HIDDEN, eggert@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> We're failing to run status_notify even though process status has >> >> changed. >> > >> > Yes, that's clear. But why do we fail to run status_notify and/or the >> > sentinel? >> >> Whenever we're about to, we discover "input" that should be handled >> first. > > Which input is that? "Keyboard" input (actually input on the X socket or equivalent), IIUC. >> > That is already a better candidate for the fix, because it >> > special-cases the read_kbd case, but read_kbd is not a boolean, it's a >> > tristate. >> >> Indeed, and this code does the right thing for all values, just like in >> all other locations that set the FD mask. > > Please tell more: how does it does TRT for both of the non-zero > values? if read_kbd is 0 (as it is in Spencer's test case), we ignore keyboard input, so we shouldn't add the keyboard fd(s) to our fd mask. if read_kbd is 1, we're not ignoring keyboard input, so we should add them: we'll read keyboard input as ordinary input and exit the loop. if read_kbd is -1, we're not ignoring keyboard input, so we should add them (but we exit in a different way) This is the same as the existing caller under the "Wait till there is something to do" comment. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:22:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:22:19 2025 Received: from localhost ([127.0.0.1]:46273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOI3-0003uW-5Q for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:22:19 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:33001) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vHOI0-0003uB-So for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:22:14 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever In-Reply-To: <87ecq93n1t.fsf@HIDDEN> (Pip Cet's message of "Fri, 07 Nov 2025 15:00:35 +0000") References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> Date: Fri, 07 Nov 2025 10:22:07 -0500 Message-ID: <ierzf8x6f6o.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1762528927; bh=idVWbueYHkZZNvdNl9KhaykhZD4K8aqWNCpOT4evbKo=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=ss4oobXPPFFAGHx2aFoLDeaW8S0G+ukrtd6j695xze4pVgMUgu3jHj7+CybKoeaQ6 m0sqqXnG6llq4OKzrBTU6R/2hI4p0KzpJksKw9nDxyStiU7QtGFn1SB7h0ImW3liRw zKDFM0hVh2A0CLJML5ZdKvXP6aqq4BUyhHiRTAO5Vnr66NpUhQp35e+YqUlxcENsst qVSpXbhXrtnnfUAvVA0yfDlEcrSYjGcAd8rUQ4GQ+sSmJ/4JkCNeXaYfuYh/c/Tw2b nhK7XgT3cOmTEkW+S2S72loZItA+CO2pvrCwS3DyqZnDFFsjN5ZccOgSXafYaqroUB qTQ1Dc7u/hLtw== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, eggert@HIDDEN, 79777 <at> debbugs.gnu.org, monnier@HIDDEN 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: -3.3 (---) Pip Cet <pipcet@HIDDEN> writes: > "Eli Zaretskii" <eliz@HIDDEN> writes: > >>> Date: Fri, 07 Nov 2025 13:06:39 +0000 >>> From: Pip Cet <pipcet@HIDDEN> >>> Cc: Stefan Monnier <monnier@HIDDEN>, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN >>> >>> "Eli Zaretskii" <eliz@HIDDEN> writes: >>> >>> > (The original patch also removed the call to thread_select, which >>> > makes even less sense.) >>> >>> Makes sense to me, I must say: if process_tick changed, we should run >>> status_notify, whether or not there is other input. The rest is >>> cosmetics (whether to redisplay, for example). >> >> First, thread_select allows another thread to take the global lock, so >> removing that call will potentially harm responsiveness of other >> threads. > > Calling it twice in rapid succession rather than just once should not > affect responsiveness. Agreed, it won't harm responsiveness since the second select call (in your patch) happens immediately after anyway. >> And second, I think you forget about keyboard input: if it's >> available, we don't want to process output from sub-processes, at >> least not in some calling scenarios. > > See the other emails. We probably want to give ordinary input priority > over sentinels, but that can be achieved without duplicating the select > call. Or we can keep the call and ignore its return value. > >>> > I actually don't think I understand the root cause(s) of the original >>> > bug. What exactly causes wait_reading_process_output loop >>> >>> We're failing to run status_notify even though process status has >>> changed. >> >> Yes, that's clear. But why do we fail to run status_notify and/or the >> sentinel? > > Whenever we're about to, we discover "input" that should be handled > first. Then we fail to handle that input, because it's on an FD we're > not actually interested in. So we infloop. This is my understanding too. >>> > I think what we see happens because sleep-for is meant to sleep >>> > unconditionally, and the process sentinel is only run when Emacs is >>> > idle (and not sleeping in sleep-for). Thus, the while loop at the end > > What you said here amounts to "sleep-for does not run sentinels". > > That contradicts both the code, which runs process sentinels in > sleep-for, and the documentation, which clearly states not only that it > does, but that it is the recommended way of doing so. > > sleep-for runs sentinels. Please also remember that sleep-for isn't necessary to trigger the bug. It happens also if you replace (sleep-for 1) with (accept-process-output nil 1). So I think we don't need to talk about sleep-for.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:21:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:21:29 2025 Received: from localhost ([127.0.0.1]:46265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOHI-0003tR-J1 for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:21:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54096) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHOHF-0003tL-Tn for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:21:27 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHOH9-0006RZ-Gc; Fri, 07 Nov 2025 10:21:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WRwuefKZe/gD4l9h9ERJIM1cmnOe2NFv05eG76PScgg=; b=d4TleyZdEds1 kCqi0rGxLmzU5V2fn/gPYygLtljk2QnnLp7VgRT8ecEJav43OzsBkSLhPZ2k7gGTYQYIdkMSPQMV5 fjw3+CUdk4x8R+VTXJogemkyfsL26ktYK4d0RUD0PMDbBmP+A0N6czLB2CeGImTgSEV9uNMO3LKLi yjM2sr2z7/uQYZxHBfi78yWjuJIDbZg5nQagZZOQc6A8UpvF94QThZ8VdOnJrlMpmCT/U9gMopo/w SV3ck0kPSP+7CzU5nghEb5ann22nKyfphsZVF5iKIkDoT42i5mGsfYvseyxDivPo8EGDWsPX6PYtF FatbKOviDt0iR3E7yoLbng==; Date: Fri, 07 Nov 2025 17:21:16 +0200 Message-Id: <868qghamxf.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87ecq93n1t.fsf@HIDDEN> (message from Pip Cet on Fri, 07 Nov 2025 15:00:35 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@HIDDEN 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: -3.3 (---) > Date: Fri, 07 Nov 2025 15:00:35 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> We're failing to run status_notify even though process status has > >> changed. > > > > Yes, that's clear. But why do we fail to run status_notify and/or the > > sentinel? > > Whenever we're about to, we discover "input" that should be handled > first. Which input is that? > > That is already a better candidate for the fix, because it > > special-cases the read_kbd case, but read_kbd is not a boolean, it's a > > tristate. > > Indeed, and this code does the right thing for all values, just like in > all other locations that set the FD mask. Please tell more: how does it does TRT for both of the non-zero values?
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:18:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:18:58 2025
Received: from localhost ([127.0.0.1]:46231 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHOEr-0003jv-RZ
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:18:58 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:41601)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vHOEn-0003jl-Lg
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:18:56 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
In-Reply-To: <87pl9u2bex.fsf@HIDDEN> (Pip Cet's message of "Fri, 07
Nov 2025 13:57:18 +0000")
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
<87pl9u2bex.fsf@HIDDEN>
Date: Fri, 07 Nov 2025 10:18:47 -0500
Message-ID: <ier346p7two.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762528727;
bh=8soTaeqNH9FsPsjY5RL/ZwA4V9s1lY70TMEaf9CXMqw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=g7S2anEOxZi3mZU8WmCnLQ2EwKqi0/r6VNviSidmvb54y2+CbeErPX1kmYjLoiSL5
toc5oDcPoS/avvSKEpcOFDuLi8MWf19bhMxV0e4w1CSOfPkPbZe7Y/I1tmsexN/Cvu
ukhffYVKwmH0MxSoLOcA9dm/pdC8siAjUBSkbf9u1aMpQ87zVGRoFfd44YF9y3xS8G
jAcE2NnZREIWHKk2KCgr98F34bBoG3MEKZnJQ6Yj4XR3eP9QiUM2yd/QQGteizK85w
xJ6OxUXW3J5XuIkFb0NsjWBtehy7gLRc4DURR7kTNHXOc/QpgojXuKqG7ko20sAND/
wNfDm3ISGOFjw==
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org,
Paul Eggert <eggert@HIDDEN>
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: -3.3 (---)
Pip Cet <pipcet@HIDDEN> writes:
> "Spencer Baugh" <sbaugh@HIDDEN> writes:
>
>> On Fri, Nov 7, 2025, 4:00=E2=80=AFAM Pip Cet <pipcet@HIDDEN> wro=
te:
>>
>> "Spencer Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of=
text editors\""
>> <bug-gnu-emacs@HIDDEN> writes:
>>
>> > The following patch fixes it, cleaning up an area of troublesome code
>> > which has caused a number of recent bugs.
>>
>> > [2. text/x-patch; 0001-Immediately-call-status_notify-on-process-tick=
.patch]...
>>
>> IIUC, this is equivalent to changing a single condition here:
>>
>> diff --git a/src/process.c b/src/process.c
>> index 33d96198573..7368e242c7d 100644
>> --- a/src/process.c
>> +++ b/src/process.c
>> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit,=
int nsecs,
>> int read_kbd,
>> &Atemp,
>> (num_pending_connects > 0 ? &Ctemp : NULL=
),
>> NULL, &timeout, NULL)
>> - <=3D 0))
>> + <=3D 0)
>> + || true)
>> {
>> /* It's okay for us to do this and then continue with
>> the loop, since timeout has already been zeroed out. =
*/
>>
>> (your patch the simplified the remaining code, but maybe it's easier to
>> understand if we go through the logical change first).
>>
>> Yes.
>
> Okay, thanks for helping me understand. My impression is we shouldn't do
> that: if input is available, and we also want to run a sentinel, it's
> better to handle the input first, then run the sentinel only when no
> further input is available. That way, even if the sentinel somehow
> causes another sentinel (or itself) to run, Emacs will stay usable.
Hm, that's fair.
>> That change looks harmless, but I think it indicates something else in
>> the code is incorrect.
>
> I think the whole approach of using two select calls is very fragile.
Agreed, I think that's the root of the problem. I have previously found
other bugs related to this update_tick select call, so I do think it's
time to just get rid of it.
> How about we just zap the timeout, so we know the next select call will
> return immediately; and then run the sentinels only if nfds =3D=3D 0 (so =
no
> further input was received)?
>
> This keeps the current priority logic, but ensures the sentinel messages
> will still be visible.
Ah, great idea! Yes, that seems like a good approach.
>> > Previously in wait_reading_process_output, if we saw that
>> > update_tick !=3D process_tick, we only called status_notify if it
>> > wasn't also some other kind of input which would cause
>> > status_notify to be called.
>>
>> I'm not sure I understand this sentence. My impression is that we called
>> status_notify in the code above if there was no input available on any
>> of the FDs compute_input_wait_mask returned, but the other select used a
>> different FD set.
>>
>> Sure sure, this sentence is describing the intention. It mostly works b=
ut didn't quite always work due to the mask difference.=20
>
> I still don't understand the sentence in your commit message, sorry.
Eh, don't worry about it, it doesn't add anything to the discussion.
>> > When these select masks are different, the "if (update_tick !=3D
>> > process_tick)" branch can detect input (in this case from file-notify)
>> > which the main select will not see, causing the busy-looping behavior.
>>
>> Why are the select masks different, though? Wouldn't it suffice to make
>> them the same, like this?
>
>> The mask can be computed in many other different ways too, if you look a=
t the code.
>
> Thanks. I wouldn't say "many", but there are a few cases, all of which
> would have to be looked at; unless we decide to avoid the second select
> call entirely and move some code, as discussed above.
Yes.
>> So this leaves a bunch of other potential bugs latent in the code.
>
> Quite possibly, but it seems to me this specific bug can be fixed on its
> own, and then we can discuss further patches as they become relevant.
>
> In summary, your patch does two things:
>
> 1. fix the infloop
> 2. give sentinels priority over ordinary input
>
> We want (1), but not (2), so can we look for a patch that does that?
Right.
> Here's my idea for how to do it, merely for demonstration at this point:
>
> diff --git a/src/process.c b/src/process.c
> index 86e83e58c56..3ba70235678 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5519,44 +5519,10 @@ wait_reading_process_output (intmax_t time_limit,=
int nsecs, int read_kbd,
> if (read_kbd < 0 && kbd_is_ours ())
> set_waiting_for_input (&timeout);
>=20=20
> - /* If status of something has changed, and no input is
> - available, notify the user of the change right away. After
> - this explicit check, we'll let the SIGCHLD handler zap
> - timeout to get our attention. */
> + /* If a process status has changed, we want to react as soon as
> + all available input has been handled. */
> if (update_tick !=3D process_tick)
> - {
> - fd_set Atemp;
> - fd_set Ctemp;
> -
> - if (kbd_on_hold_p ())
> - FD_ZERO (&Atemp);
> - else
> - compute_input_wait_mask (&Atemp);
> - compute_write_mask (&Ctemp);
> -
> - /* If a process status has changed, the child signal pipe
> - will likely be readable. We want to ignore it for now,
> - because otherwise we wouldn't run into a timeout
> - below. */
> - int fd =3D child_signal_read_fd;
> - eassert (fd < FD_SETSIZE);
> - if (0 <=3D fd)
> - FD_CLR (fd, &Atemp);
> -
> - timeout =3D make_timespec (0, 0);
> - if ((thread_select (pselect, max_desc + 1,
> - &Atemp,
> - (num_pending_connects > 0 ? &Ctemp : NULL),
> - NULL, &timeout, NULL)
> - <=3D 0))
> - {
> - /* It's okay for us to do this and then continue with
> - the loop, since timeout has already been zeroed out. */
> - clear_waiting_for_input ();
> - got_some_output =3D status_notify (NULL, wait_proc);
> - if (do_display) redisplay_preserve_echo_area (13);
> - }
> - }
> + timeout =3D make_timespec (0, 0);
>=20=20
> /* Don't wait for output from a non-running process. Just
> read whatever data has already been received. */
> @@ -5844,6 +5810,15 @@ wait_reading_process_output (intmax_t time_limit, =
int nsecs, int read_kbd,
>=20=20
> if (nfds =3D=3D 0)
> {
> + /* There was no input, but the status of a process has
> + changed. Run the sentinel, and redisplay so the user can
> + see the sentinel message. */
> + if (update_tick !=3D process_tick)
> + {
> + got_some_output =3D status_notify (NULL, wait_proc);
> + if (do_display) redisplay_preserve_echo_area (13);
> + }
> +
> /* Exit the main loop if we've passed the requested timeout,
> or have read some bytes from our wait_proc (either directly
> in this call or indirectly through timers / process filters=
),
>
> Do you have other ideas? (Note that the clear_waiting_on_input call also
> becomes unnecessary in this patch).
I think this is a very elegant solution, I like it.
It nicely preserves the existing behavior of prioritizing input over
sentinels, while fixing the buggy implementation with two select calls.
I prefer this patch over the one I posted. If it passes make check and
my repro, I'm in favor of installing it.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:00:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:00:52 2025 Received: from localhost ([127.0.0.1]:46114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHNxL-0003BR-GZ for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:00:52 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:56365) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHNxH-0003BJ-38 for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:00:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762527640; x=1762786840; bh=rrr33KsIkzkhW0uLT7UrP4XmRAmBgwBtPDkrwTpFPWA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=XgcMEpNcEWucwFjoXGcW04tWy2x9s7tmjmUvlJEL1mbHvQ3AhucBkSE0NPxevhJK3 lr2ZYUrQWbkhs/+rUsHMav+Qjq3Chn/8d4YnKzfCDd1TTjFCx9zJfFwp+wV0M/j1y4 xoLhT6TeyhMnJChTOTyd4WfEZNI6vIcvFq1en0E2r0hMuHNortUtw3PIWPK334oXVf 76w8Pj0xK0Brj3CHrsxHDFVGFKEVtYy/qJ1fBFWudwkFB2FM+GEvlTHNEpvXTiYFGT SXENfHHTQtPcPP70c9zivaFfwn6kiYc02HtYdpO2J0Qc1ZaBRul4Pec48WvscdQmUL 7rSVUMhBq2JTw== Date: Fri, 07 Nov 2025 15:00:35 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <87ecq93n1t.fsf@HIDDEN> In-Reply-To: <86h5v69bbe.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a09a58b2b8335a0a32696927cdcb3a92de9f69dd MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@HIDDEN 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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Fri, 07 Nov 2025 13:06:39 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: Stefan Monnier <monnier@HIDDEN>, 79777 <at> debbugs.gnu.org, sb= augh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> > (The original patch also removed the call to thread_select, which >> > makes even less sense.) >> >> Makes sense to me, I must say: if process_tick changed, we should run >> status_notify, whether or not there is other input. The rest is >> cosmetics (whether to redisplay, for example). > > First, thread_select allows another thread to take the global lock, so > removing that call will potentially harm responsiveness of other > threads. Calling it twice in rapid succession rather than just once should not affect responsiveness. > And second, I think you forget about keyboard input: if it's > available, we don't want to process output from sub-processes, at > least not in some calling scenarios. See the other emails. We probably want to give ordinary input priority over sentinels, but that can be achieved without duplicating the select call. Or we can keep the call and ignore its return value. >> > I actually don't think I understand the root cause(s) of the original >> > bug. What exactly causes wait_reading_process_output loop >> >> We're failing to run status_notify even though process status has >> changed. > > Yes, that's clear. But why do we fail to run status_notify and/or the > sentinel? Whenever we're about to, we discover "input" that should be handled first. Then we fail to handle that input, because it's on an FD we're not actually interested in. So we infloop. >> > I think what we see happens because sleep-for is meant to sleep >> > unconditionally, and the process sentinel is only run when Emacs is >> > idle (and not sleeping in sleep-for). Thus, the while loop at the end What you said here amounts to "sleep-for does not run sentinels". That contradicts both the code, which runs process sentinels in sleep-for, and the documentation, which clearly states not only that it does, but that it is the recommended way of doing so. sleep-for runs sentinels. >> The problem is that "the next select" doesn't look at the keyboard fd, >> but our "check" select does, so what ends up happening is that we skip >> the process status change (thinking the next select will do it), but the >> next select doesn't exit the loop, because it ignores the keyboard fd. > > What is "the next select"? which of the two calls to thread_select do There are two calls, so when I say "the next select", I mean the second one. > you allude to here, and why do you say that we need to look at > keyboard input? We don't. The bug is that the first select looks at keyboard input, not that the second select fails to. >> Just for completeness, there was a thinko in my last patch: >> >> diff --git a/src/process.c b/src/process.c >> index 86e83e58c56..099e205344b 100644 >> --- a/src/process.c >> +++ b/src/process.c >> @@ -5530,7 +5530,9 @@ wait_reading_process_output (intmax_t time_limit, = int nsecs, int read_kbd, >> >> if (kbd_on_hold_p ()) >> FD_ZERO (&Atemp); >> - else >> + else if (! read_kbd) >> +=09 compute_non_keyboard_wait_mask (&Atemp); >> +=09 else >> compute_input_wait_mask (&Atemp); >> =09 compute_write_mask (&Ctemp); >> >> >> would have been the correct patch, sorry about that. > > That is already a better candidate for the fix, because it > special-cases the read_kbd case, but read_kbd is not a boolean, it's a > tristate. Indeed, and this code does the right thing for all values, just like in all other locations that set the FD mask. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 14:17:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 09:17:38 2025 Received: from localhost ([127.0.0.1]:45921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHNHV-00017o-9g for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 09:17:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57060) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHNHS-00017g-9W for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 09:17:35 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHNHL-0000L2-Iv; Fri, 07 Nov 2025 09:17:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5A10va8ApnDbAV+FO6sei+hpXc4qE83mZL4wXIea1Uo=; b=HhdHKlAPDK7G bbvOQ9orlfhH/OWNnyA0iOtllkilPBB34MX1mqLNQNcjUQ3GHDFN3dIG4fVRhOJKHj4f+xZBvag31 daSTvul3mKuMQl0kRy7XKGNxZfCWXmfqq6X9LYfmie4GGjSU8au49LwnITfgbjvlBSaKnr/5au+OM 5GGGxo2eBwHdlj873VZeiXnNfoYPmBQ06+CGurMVD45CXuCj1bAusSHywfP/SNXEjZVmccr4d9Xn6 HAQ0/S2pDsJm0pnXyX5HK3wDyzjKxcboIWrAHFu5Ta7cYbqWbMOCn6jim38eRetEP61n3k4oY+2H+ WhYVnpopErAJvaO7nOvjuQ==; Date: Fri, 07 Nov 2025 16:17:25 +0200 Message-Id: <86h5v69bbe.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87v7jm2drb.fsf@HIDDEN> (message from Pip Cet on Fri, 07 Nov 2025 13:06:39 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@HIDDEN 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: -3.3 (---) > Date: Fri, 07 Nov 2025 13:06:39 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: Stefan Monnier <monnier@HIDDEN>, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > (The original patch also removed the call to thread_select, which > > makes even less sense.) > > Makes sense to me, I must say: if process_tick changed, we should run > status_notify, whether or not there is other input. The rest is > cosmetics (whether to redisplay, for example). First, thread_select allows another thread to take the global lock, so removing that call will potentially harm responsiveness of other threads. And second, I think you forget about keyboard input: if it's available, we don't want to process output from sub-processes, at least not in some calling scenarios. > > I actually don't think I understand the root cause(s) of the original > > bug. What exactly causes wait_reading_process_output loop > > We're failing to run status_notify even though process status has > changed. Yes, that's clear. But why do we fail to run status_notify and/or the sentinel? > > indefinitely because there's a single (AFAIU) file notification? > > Also, on MS-Windows the file notifications don't work via > > pselect-testing of file descriptors, but the test case hangs anyway. > > Interesting. Do any of the patches help? I didn't try them, because they won't teach me anything at this stage. But see my other mail with description of some experiments I did with small variations of the original script. We need to explain all of those behaviors before we discuss patches, IMO. > > I think what we see happens because sleep-for is meant to sleep > > unconditionally, and the process sentinel is only run when Emacs is > > idle (and not sleeping in sleep-for). Thus, the while loop at the end > > That's incorrect. status_notify calls exec_sentinel, which runs the > sentinel even though Emacs is sleeping in sleep-for. I meant we don't call status_notify because Emacs is not idle. > > of the test program prevents Emacs from running the sentinel. In > > which case what we see is the expected and documented behavior, not a > > bug at all. > > The documentation says: > > A sentinel runs only while Emacs is waiting (e.g., for terminal > input, or for time to elapse, or for process output). This avoids the > > I think sleep-for counts as "Emacs is waiting for time to elapse". I'm not sure, that's the whole point of what I'm saying above. sleep-for does not wait for input, it waits for the time to pass. > The manual goes on to recommend that sleep-for be used to ensure > sentinels can run. So maybe the manual is wrong. Or please explain what happens here, and how the file notifications are involved. (I think the file notifications are largely a red herring: they just keep Emacs busy for enough time to trigger the behavior. IOW, the issue here is fine timing of the process demise vs the loop with sleep-for.) > > So I think there's more to this than meets the eye, and we should > > understand the problem (such that it is) better before we discuss the > > solutions (if they are needed). > > I agree. What I think I understand so far is: > > The old logic was this: > > 1. a process status has changed > 2. we check whether the next select will definitely return right away > because input is available > 3. if so, wo don't handle the process status change, because we're about > to exit the loop anyway You begin the description too late. It should begin with make-process, because, on the one hand, it takes Emacs to get to the wait loop, and OTOH it takes time for the process to die. So the description should start earlier. In particular, we might have already checked the child pipe and have seen that it's ready to be read. And the inotify descriptor is perhaps also a factor. > The problem is that "the next select" doesn't look at the keyboard fd, > but our "check" select does, so what ends up happening is that we skip > the process status change (thinking the next select will do it), but the > next select doesn't exit the loop, because it ignores the keyboard fd. What is "the next select"? which of the two calls to thread_select do you allude to here, and why do you say that we need to look at keyboard input? and what input is available in 2 above? > Just for completeness, there was a thinko in my last patch: > > diff --git a/src/process.c b/src/process.c > index 86e83e58c56..099e205344b 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -5530,7 +5530,9 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, > > if (kbd_on_hold_p ()) > FD_ZERO (&Atemp); > - else > + else if (! read_kbd) > + compute_non_keyboard_wait_mask (&Atemp); > + else > compute_input_wait_mask (&Atemp); > compute_write_mask (&Ctemp); > > > would have been the correct patch, sorry about that. That is already a better candidate for the fix, because it special-cases the read_kbd case, but read_kbd is not a boolean, it's a tristate.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 13:57:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 08:57:34 2025
Received: from localhost ([127.0.0.1]:45864 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHMy5-0000Pm-Gx
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:57:34 -0500
Received: from mail-4316.protonmail.ch ([185.70.43.16]:18435)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHMy2-0000Pe-0x
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:57:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762523843; x=1762783043;
bh=4ETviTFQQcEpst3QtqgMuR4R+Xq0RGUKzbtXUhAgP28=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=JWTy+LzswIvDKWFwwhUpKjjExwHQfZTCmetDHU2E6ETlHetTfYpqx2J3pjpej9uty
mELjnLjfAA7r6EWCKc1GcQgpVMCiAB5eyo87EVxlsYUjL9Mu/9Ko+A1T/W4C0qahZC
eOtBtUTvxsdr3SUejSVbBbDCYHdv+iVEzG1BQznXhEXOFfsOHdnUcPo6w2gWs0FZIN
4yspdlb5pCvXOUh+fFtnZgaerTmJvxpPVf9a9cxc7/qQ3K5XnwMh2zj3xWUsZ3MNy6
0wxgNKyQGjT/ia/gU2G0zb29hxmlDUe5zT/VLrA+K23r6DtlEKy/riP1lScXT4+FJj
Uv1Ow6X3UfAQA==
Date: Fri, 07 Nov 2025 13:57:18 +0000
To: Spencer Baugh <sbaugh@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
Message-ID: <87pl9u2bex.fsf@HIDDEN>
In-Reply-To: <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: b42a55185facd2001962798b6e83fc18b78e7676
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org,
Paul Eggert <eggert@HIDDEN>
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 (-)
"Spencer Baugh" <sbaugh@HIDDEN> writes:
> On Fri, Nov 7, 2025, 4:00=E2=80=AFAM Pip Cet <pipcet@HIDDEN> wrot=
e:
>
> "Spencer Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of =
text editors\""
> <bug-gnu-emacs@HIDDEN> writes:
>
> > The following patch fixes it, cleaning up an area of troublesome code
> > which has caused a number of recent bugs.
>
> > [2. text/x-patch; 0001-Immediately-call-status_notify-on-process-tick.=
patch]...
>
> IIUC, this is equivalent to changing a single condition here:
>
> diff --git a/src/process.c b/src/process.c
> index 33d96198573..7368e242c7d 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, =
int nsecs,
> int read_kbd,
> &Atemp,
> (num_pending_connects > 0 ? &Ctemp : NULL)=
,
> NULL, &timeout, NULL)
> - <=3D 0))
> + <=3D 0)
> + || true)
> {
> /* It's okay for us to do this and then continue with
> the loop, since timeout has already been zeroed out. *=
/
>
> (your patch the simplified the remaining code, but maybe it's easier to
> understand if we go through the logical change first).
>
> Yes.
Okay, thanks for helping me understand. My impression is we shouldn't do
that: if input is available, and we also want to run a sentinel, it's
better to handle the input first, then run the sentinel only when no
further input is available. That way, even if the sentinel somehow
causes another sentinel (or itself) to run, Emacs will stay usable.
> That change looks harmless, but I think it indicates something else in
> the code is incorrect.
I think the whole approach of using two select calls is very fragile.
How about we just zap the timeout, so we know the next select call will
return immediately; and then run the sentinels only if nfds =3D=3D 0 (so no
further input was received)?
This keeps the current priority logic, but ensures the sentinel messages
will still be visible.
> > Previously in wait_reading_process_output, if we saw that
> > update_tick !=3D process_tick, we only called status_notify if it
> > wasn't also some other kind of input which would cause
> > status_notify to be called.
>
> I'm not sure I understand this sentence. My impression is that we called
> status_notify in the code above if there was no input available on any
> of the FDs compute_input_wait_mask returned, but the other select used a
> different FD set.
>
> Sure sure, this sentence is describing the intention. It mostly works bu=
t didn't quite always work due to the mask difference.=20
I still don't understand the sentence in your commit message, sorry.
> > When these select masks are different, the "if (update_tick !=3D
> > process_tick)" branch can detect input (in this case from file-notify)
> > which the main select will not see, causing the busy-looping behavior.
>
> Why are the select masks different, though? Wouldn't it suffice to make
> them the same, like this?
> The mask can be computed in many other different ways too, if you look at=
the code.
Thanks. I wouldn't say "many", but there are a few cases, all of which
would have to be looked at; unless we decide to avoid the second select
call entirely and move some code, as discussed above.
> So this leaves a bunch of other potential bugs latent in the code.
Quite possibly, but it seems to me this specific bug can be fixed on its
own, and then we can discuss further patches as they become relevant.
In summary, your patch does two things:
1. fix the infloop
2. give sentinels priority over ordinary input
We want (1), but not (2), so can we look for a patch that does that?
Here's my idea for how to do it, merely for demonstration at this point:
diff --git a/src/process.c b/src/process.c
index 86e83e58c56..3ba70235678 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5519,44 +5519,10 @@ wait_reading_process_output (intmax_t time_limit, i=
nt nsecs, int read_kbd,
if (read_kbd < 0 && kbd_is_ours ())
=09set_waiting_for_input (&timeout);
=20
- /* If status of something has changed, and no input is
-=09 available, notify the user of the change right away. After
-=09 this explicit check, we'll let the SIGCHLD handler zap
-=09 timeout to get our attention. */
+ /* If a process status has changed, we want to react as soon as
+=09 all available input has been handled. */
if (update_tick !=3D process_tick)
-=09{
-=09 fd_set Atemp;
-=09 fd_set Ctemp;
-
- if (kbd_on_hold_p ())
- FD_ZERO (&Atemp);
- else
- compute_input_wait_mask (&Atemp);
-=09 compute_write_mask (&Ctemp);
-
-=09 /* If a process status has changed, the child signal pipe
-=09 will likely be readable. We want to ignore it for now,
-=09 because otherwise we wouldn't run into a timeout
-=09 below. */
-=09 int fd =3D child_signal_read_fd;
-=09 eassert (fd < FD_SETSIZE);
-=09 if (0 <=3D fd)
-=09 FD_CLR (fd, &Atemp);
-
-=09 timeout =3D make_timespec (0, 0);
-=09 if ((thread_select (pselect, max_desc + 1,
-=09=09=09 &Atemp,
-=09=09=09 (num_pending_connects > 0 ? &Ctemp : NULL),
-=09=09=09 NULL, &timeout, NULL)
-=09 <=3D 0))
-=09 {
-=09 /* It's okay for us to do this and then continue with
-=09=09 the loop, since timeout has already been zeroed out. */
-=09 clear_waiting_for_input ();
-=09 got_some_output =3D status_notify (NULL, wait_proc);
-=09 if (do_display) redisplay_preserve_echo_area (13);
-=09 }
-=09}
+=09timeout =3D make_timespec (0, 0);
=20
/* Don't wait for output from a non-running process. Just
=09 read whatever data has already been received. */
@@ -5844,6 +5810,15 @@ wait_reading_process_output (intmax_t time_limit, in=
t nsecs, int read_kbd,
=20
if (nfds =3D=3D 0)
=09{
+=09 /* There was no input, but the status of a process has
+=09 changed. Run the sentinel, and redisplay so the user can
+=09 see the sentinel message. */
+=09 if (update_tick !=3D process_tick)
+=09 {
+=09 got_some_output =3D status_notify (NULL, wait_proc);
+=09 if (do_display) redisplay_preserve_echo_area (13);
+=09 }
+
/* Exit the main loop if we've passed the requested timeout,
or have read some bytes from our wait_proc (either directly
in this call or indirectly through timers / process filters),
Do you have other ideas? (Note that the clear_waiting_on_input call also
becomes unnecessary in this patch).
Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 13:52:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 08:52:41 2025
Received: from localhost ([127.0.0.1]:45853 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHMtN-0000Fp-89
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:52:41 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:49670)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHMtI-0000Fh-TY
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:52:39 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vHMtB-0005CJ-FN; Fri, 07 Nov 2025 08:52:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=UI7bPy7thaxZSaoZoixDKw4IhihDeUkVrXUcc9d5GSE=; b=lVAvXISTw1A7WX7kDfBo
OgPKJacZOUsNTRchOsctPIjI5Wv472pcASHh68j+xDQM5DJIrNhxzPzwaUk0dAY6giBfEzcHsFUfi
gZVI7hgADMwRLZYKoXdL55sQrcq29gp8YYiWdLns0aUX/Jq/bJuSPjA0pUAo365mG64V/sIpmk1Hm
VvF/EoLJcCwWba24H0y0I8tkK9/DX2KpkrRVhcR3qkmoCUe+BTkNYxxdU/FjMt2+g0WOks5fBmao2
lBPfScjr0lH7+FYqZXuaG14hjRwcZ08HbFEcaHF+r3lkSZxHIQ650veu6WeG+IVqvW/kJR/U6/E0t
dko7WgZzgpQY1Q==;
Date: Fri, 07 Nov 2025 15:52:26 +0200
Message-Id: <86ikfm9ch1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <CAO=BR8Mu2FzVpjgTiu6Kd9aO5rDEB=nvxUA42koHqRVA8=CnYA@HIDDEN>
(message from Spencer Baugh on Fri, 7 Nov 2025 07:34:12 -0500)
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<86ldki9hla.fsf@HIDDEN>
<CAO=BR8Mu2FzVpjgTiu6Kd9aO5rDEB=nvxUA42koHqRVA8=CnYA@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: dmitry@HIDDEN, pipcet@HIDDEN, eggert@HIDDEN,
monnier@HIDDEN, 79777 <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: -3.3 (---)
> From: Spencer Baugh <sbaugh@HIDDEN>
> Date: Fri, 7 Nov 2025 07:34:12 -0500
> Cc: Pip Cet <pipcet@HIDDEN>, Stefan Monnier <monnier@HIDDEN>,
> 79777 <at> debbugs.gnu.org, Dmitry Gutov <dmitry@HIDDEN>, eggert@HIDDEN
>
> On Fri, Nov 7, 2025, 7:02 AM Eli Zaretskii <eliz@HIDDEN> wrote:
>
> > Date: Fri, 07 Nov 2025 09:00:50 +0000
> > From: Pip Cet via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> >
> > IIUC, this is equivalent to changing a single condition here:
> >
> > diff --git a/src/process.c b/src/process.c
> > index 33d96198573..7368e242c7d 100644
> > --- a/src/process.c
> > +++ b/src/process.c
> > @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int
> read_kbd,
> > &Atemp,
> > (num_pending_connects > 0 ? &Ctemp : NULL),
> > NULL, &timeout, NULL)
> > - <= 0))
> > + <= 0)
> > + || true)
> > {
> > /* It's okay for us to do this and then continue with
> > the loop, since timeout has already been zeroed out. */
>
> That might be so, but it doesn't mean it makes sense to do this. For
> example, why should we call redisplay if there's some input available?
>
> (The original patch also removed the call to thread_select, which
> makes even less sense.)
>
> I actually don't think I understand the root cause(s) of the original
> bug. What exactly causes wait_reading_process_output loop
> indefinitely because there's a single (AFAIU) file notification?
> Also, on MS-Windows the file notifications don't work via
> pselect-testing of file descriptors, but the test case hangs anyway.
>
> I think what we see happens because sleep-for is meant to sleep
> unconditionally, and the process sentinel is only run when Emacs is
> idle (and not sleeping in sleep-for). Thus, the while loop at the end
> of the test program prevents Emacs from running the sentinel. In
> which case what we see is the expected and documented behavior, not a
> bug at all.
>
> Nope: the bug happens just the same if the sleep-for is replaced with accept-process-output.
I don't see how this affects the conclusion, sorry. You have to
explain more about the root cause. What is your explanation of the
fact that the test case hangs on Windows (well, I can un-hang it with
C-g, but still) even though pselect isn't involved in receiving file
notifications? And if, instead of running the test via load-file, I
insert the code of your test program into *scratch* and the run it by
"M-x eval-region", it doesn't hang at all on MS-Windows (but does hang
on GNU/Linux) -- why? And if I insert (sit-for 1) before the while
loop, it doesn't hang at all -- again, why?
> I have worked closely with this code for a while now and discovered and fixed many bugs in it. So why won't
> you consider my change, even though it's not trivial? wait_reading_process_output has lots of bugs. We
> have to allow it to change non-trivially to fix those bugs.
I already explained why. Let me try again:
wait_reading_process_output supports several distinct use cases, each
one of them with its specific requirements and expectations. For
example, the uses which wait for keyboard input expect it to return
immediately as soon as input is available in the keyboard queue. By
contrast, uses which want to read input from sub-processes don't
necessarily expect to return immediately, but tend to let Emacs read
enough input first. And there are other use cases. Therefore,
changes that affect all of the uses without distinction are not
acceptable, since they are likely to break some of the uses.
Besides, until we have a good understanding of the root cause in this
particular case, it is simply wrong to discuss patches. See above.
So let's first have a clear understanding of what happens here and of
the resulting behavior, so that we could explain the behaviors of all
of the variants mentioned above.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 13:06:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 08:06:54 2025
Received: from localhost ([127.0.0.1]:45754 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHMB4-0006rT-BR
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:06:54 -0500
Received: from mail-10628.protonmail.ch ([79.135.106.28]:13305)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHMAz-0006r8-F7
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:06:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762520802; x=1762780002;
bh=nsJTFKtUkCDba/MKUiMYoIbzGAKzTIMTEJ021XVJyyI=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=TWGv6fPYkGB/nVM+1KbgkYzf3iZ6vjHJrB+hQbm6ErS/3qEGrkrzHja2MqeHkH1t9
ACkBnnsxPKFJXhZsGXJ0BDoEMIx1OstiliN6KtG7/CZYl45tL3+Lw4R6nN7BIlwtjS
ojszfD6y3o7JdZAxRbWt2L5QwflhwFYT0fR2blQxthBrHkSY6/Y301aHY2CnOrbhWx
Wsyy57tqfTKMHg/i0IJTyzl8SVT0gxJap+n0ShttO1q17bx57Vlt/1gJleg2rRHtAX
lbgsQLSOclnHExsaCfovhbsZW6hbFj89Pws559OmYJBIdyqBKWuccJekEnIGtqvUNi
YGVNlM+C8apyw==
Date: Fri, 07 Nov 2025 13:06:39 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
Message-ID: <87v7jm2drb.fsf@HIDDEN>
In-Reply-To: <86ldki9hla.fsf@HIDDEN>
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<86ldki9hla.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: d744bbec28778e33b5c42f1f54dd6256203f67ee
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
Stefan Monnier <monnier@HIDDEN>, dmitry@HIDDEN
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 (-)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Date: Fri, 07 Nov 2025 09:00:50 +0000
>> From: Pip Cet via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>> IIUC, this is equivalent to changing a single condition here:
>>
>> diff --git a/src/process.c b/src/process.c
>> index 33d96198573..7368e242c7d 100644
>> --- a/src/process.c
>> +++ b/src/process.c
>> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, =
int nsecs, int read_kbd,
>> &Atemp,
>> (num_pending_connects > 0 ? &Ctemp : NULL)=
,
>> NULL, &timeout, NULL)
>> - <=3D 0))
>> + <=3D 0)
>> + || true)
>> {
>> /* It's okay for us to do this and then continue with
>> the loop, since timeout has already been zeroed out. *=
/
>
> That might be so, but it doesn't mean it makes sense to do this.
I agree; I only did something that should have equivalent effects to the
original patch.
> (The original patch also removed the call to thread_select, which
> makes even less sense.)
Makes sense to me, I must say: if process_tick changed, we should run
status_notify, whether or not there is other input. The rest is
cosmetics (whether to redisplay, for example).
> I actually don't think I understand the root cause(s) of the original
> bug. What exactly causes wait_reading_process_output loop
We're failing to run status_notify even though process status has
changed.
> indefinitely because there's a single (AFAIU) file notification?
> Also, on MS-Windows the file notifications don't work via
> pselect-testing of file descriptors, but the test case hangs anyway.
Interesting. Do any of the patches help?
> I think what we see happens because sleep-for is meant to sleep
> unconditionally, and the process sentinel is only run when Emacs is
> idle (and not sleeping in sleep-for). Thus, the while loop at the end
That's incorrect. status_notify calls exec_sentinel, which runs the
sentinel even though Emacs is sleeping in sleep-for.
> of the test program prevents Emacs from running the sentinel. In
> which case what we see is the expected and documented behavior, not a
> bug at all.
The documentation says:
A sentinel runs only while Emacs is waiting (e.g., for terminal
input, or for time to elapse, or for process output). This avoids the
I think sleep-for counts as "Emacs is waiting for time to elapse".
The manual goes on to recommend that sleep-for be used to ensure
sentinels can run.
> So I think there's more to this than meets the eye, and we should
> understand the problem (such that it is) better before we discuss the
> solutions (if they are needed).
I agree. What I think I understand so far is:
The old logic was this:
1. a process status has changed
2. we check whether the next select will definitely return right away
because input is available
3. if so, wo don't handle the process status change, because we're about
to exit the loop anyway
The problem is that "the next select" doesn't look at the keyboard fd,
but our "check" select does, so what ends up happening is that we skip
the process status change (thinking the next select will do it), but the
next select doesn't exit the loop, because it ignores the keyboard fd.
Just for completeness, there was a thinko in my last patch:
diff --git a/src/process.c b/src/process.c
index 86e83e58c56..099e205344b 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5530,7 +5530,9 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,
=20
if (kbd_on_hold_p ())
FD_ZERO (&Atemp);
- else
+ else if (! read_kbd)
+=09 compute_non_keyboard_wait_mask (&Atemp);
+=09 else
compute_input_wait_mask (&Atemp);
=09 compute_write_mask (&Ctemp);
=20
would have been the correct patch, sorry about that.
Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 12:58:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 07:58:10 2025
Received: from localhost ([127.0.0.1]:45738 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHM2c-0006Yj-2e
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:58:10 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:53879)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vHM2X-0006YM-ST
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:58:07 -0500
Received: from mail-lf1-f69.google.com ([209.85.167.69])
by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128)
(Exim 4.98.2) id 1vHM2S-00000001ax5-1BnR for 79777 <at> debbugs.gnu.org;
Fri, 07 Nov 2025 07:58:00 -0500
Received: by mail-lf1-f69.google.com with SMTP id
2adb3069b0e04-57986226b53so552735e87.3
for <79777 <at> debbugs.gnu.org>; Fri, 07 Nov 2025 04:58:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=janestreet.com; s=google; t=1762520279; x=1763125079; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=u1rHdWt+zYnJLpiwj6cDGa+lRWpSd3Tnrvs//q2SvCo=;
b=uOSzkPRac5MhNOio5fE88MsA8WEbfSYLcCaAIRPF/oLE2JC2ij2oiAiz6sxM4tlZRS
Vjh/8QYXFyolBApgT5X3qdfaQl8x3HpvYN0kux4TeSPPxk7twhw/z2GlYSzFHuNqifp+
uE/oIhoM2336UrhZnx+5y9HU/iMTFOxQTZyt0=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762520280;
bh=u1rHdWt+zYnJLpiwj6cDGa+lRWpSd3Tnrvs//q2SvCo=;
h=References:In-Reply-To:From:Date:Subject:To:Cc;
b=skS4HXR3FREmRhfry2ub3P2DqBvFJ8IGgklNtx2TWlqJj47fvCDnOe85CRMQLjItn
0+B37mqqz5wclIZNjKLWRJHqxcvHODYNKXpfVXb/T2j/+tXL5YPHVKi7P5rks3WcoM
sqJZClx9xnLBDXy6F7WYexkyELXN6ctVxSOERQBTH4hETG25xV3ZrbMD2o5SH3GXFb
XC0gFeJxd5s37kCX6mkSIP8pk3OdoaC7rJzjbn9w5pblzz9/VCpD1E2D4jI+rzOuOe
fHdAbT6FZBss2D8xy7iMxRAfPbxmOyYqZHz7uzLj80noq4rQWg1IXghyO8WrecNsKq
uJ9s+r2o0yAyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1762520279; x=1763125079;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=u1rHdWt+zYnJLpiwj6cDGa+lRWpSd3Tnrvs//q2SvCo=;
b=bUs9QRTTLNapvm9Krj8iBnGRE/8k6KsNuApJb5u9o4dcH4RzoSkGHHgHhJH/Ywh7wA
0NRo4m6Xp03pS0EqeetwJnJSsH7zDTFMCNmo1uqPcIDsq/ivpaa88MLZa5V8w05xZYgA
S9zM8a7hmcH3wehb7N1ALOwF3/p0VFQdU3AfI4mRLQku3PkTJqdSLu0lxUTU9FTtyrco
kF644iblz4tZ/YQUd2dOxuL2incOtbT/OSeuxhwVyiAXp2MPkCzsdW052Fxln+kLLHVj
R62IEgfGy4QrCWi0b8yqaiqgZnnjZM+FotP3VKHxQBjzrjHVK1TfvIs0Uxv9gr0B+MUn
pUOQ==
X-Gm-Message-State: AOJu0YywFLNv/Qo5S726kS7FSCOgTjSWgGSk8wL1RGY7GTrf3//xnAba
zOiHKfDRPLJuC2KZ/KTMVy+PPNEWizcpv5fhutCZV3dwasN0T9ZVX8ZsYq/JO6vUZvUkKaengzy
9lu76R3ODa2A7j/QXTdoz69xVrYatZtS9LL1ZYg7SZCHjHOexZwnkH4hTsbefV8cb7X1TjqOaym
neCnpmrfpIb5ZNeJA1CeF46HQV+WamzQ==
X-Gm-Gg: ASbGncs73ef2yLpH5xMDszdVmTRXEFvqUKYV1/Uf8FnVZ/OutSpenNefUgdBBpX2RI7
Xg6/LMDim6sQcQvwIZ4x9zttebyCWm4YUZJZG3psHvd+4JNvQs19XlVe1LTRDogEI607pg/qZk+
iOFvwwpUS3Xu27G6W7Ulbi9jooMYf3j4O0gfoMbBiVu+QgPlo90Fy04dc=
X-Received: by 2002:a05:6512:3d04:b0:594:20d3:6ba9 with SMTP id
2adb3069b0e04-59456b7dc63mr1112004e87.23.1762520279001;
Fri, 07 Nov 2025 04:57:59 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFb/z0DAezMhUJLVF9bZJJbaoT9/O65FCM5XkKjkZDAGcVTmq/liSNSNPX5eTKzp7Z+XayxDHXdipG69T+SyFY=
X-Received: by 2002:a05:6512:3d04:b0:594:20d3:6ba9 with SMTP id
2adb3069b0e04-59456b7dc63mr1111988e87.23.1762520278540; Fri, 07 Nov 2025
04:57:58 -0800 (PST)
MIME-Version: 1.0
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
In-Reply-To: <87346qb4jo.fsf@HIDDEN>
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Fri, 7 Nov 2025 07:57:47 -0500
X-Gm-Features: AWmQ_bn8yjyoyXvZ42LOil6mTg7k7EhXZpyuMoUx56AKt1UhadeT6t4l7KZ2pa8
Message-ID: <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
To: Pip Cet <pipcet@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000001caef3064300bb5b"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org,
Paul Eggert <eggert@HIDDEN>
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: -3.3 (---)
--0000000000001caef3064300bb5b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 7, 2025, 4:00=E2=80=AFAM Pip Cet <pipcet@HIDDEN> wrote:
> "Spencer Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of
> text editors\"" <bug-gnu-emacs@HIDDEN> writes:
>
> > The following patch fixes it, cleaning up an area of troublesome code
> > which has caused a number of recent bugs.
>
> > [2. text/x-patch;
> 0001-Immediately-call-status_notify-on-process-tick.patch]...
>
> IIUC, this is equivalent to changing a single condition here:
>
> diff --git a/src/process.c b/src/process.c
> index 33d96198573..7368e242c7d 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit,
> int nsecs, int read_kbd,
> &Atemp,
> (num_pending_connects > 0 ? &Ctemp : NULL),
> NULL, &timeout, NULL)
> - <=3D 0))
> + <=3D 0)
> + || true)
> {
> /* It's okay for us to do this and then continue with
> the loop, since timeout has already been zeroed out. */
>
> (your patch the simplified the remaining code, but maybe it's easier to
> understand if we go through the logical change first).
>
Yes.
That change looks harmless, but I think it indicates something else in
> the code is incorrect.
>
> > Previously in wait_reading_process_output, if we saw that
> > update_tick !=3D process_tick, we only called status_notify if it
> > wasn't also some other kind of input which would cause
> > status_notify to be called.
>
> I'm not sure I understand this sentence. My impression is that we called
> status_notify in the code above if there was no input available on any
> of the FDs compute_input_wait_mask returned, but the other select used a
> different FD set.
>
Sure sure, this sentence is describing the intention. It mostly works but
didn't quite always work due to the mask difference.
> My initial assessment of the issue is that it's caused by a difference
> > in the select mask calculated by the "if (update_tick !=3D process_tick=
)"
> > branch and the main select mask, which can happen when read_kbd is 0 or
> > in various other cases.
>
> That sounds likely to me.
>
> > When these select masks are different, the "if (update_tick !=3D
> > process_tick)" branch can detect input (in this case from file-notify)
> > which the main select will not see, causing the busy-looping behavior.
>
> Why are the select masks different, though? Wouldn't it suffice to make
> them the same, like this?
>
It would, but this code doesn't do that.
diff --git a/src/process.c b/src/process.c
> index 86e83e58c56..3e58ffb4a7a 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5530,6 +5530,8 @@ wait_reading_process_output (intmax_t time_limit,
> int nsecs, int read_kbd,
>
> if (kbd_on_hold_p ())
> FD_ZERO (&Atemp);
> + else if (! read_kbd)
> + compute_non_keyboard_wait_mask (&Available);
> else
> compute_input_wait_mask (&Atemp);
> compute_write_mask (&Ctemp);
>
The mask can be computed in many other different ways too, if you look at
the code.
So this leaves a bunch of other potential bugs latent in the code.
--0000000000001caef3064300bb5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 7, 2025, 4:00=E2=80=
=AFAM Pip Cet <<a href=3D"mailto:pipcet@HIDDEN">pipcet@protonmai=
l.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"Spencer =
Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of text ed=
itors\"" <<a href=3D"mailto:bug-gnu-emacs@HIDDEN" target=3D"_=
blank" rel=3D"noreferrer">bug-gnu-emacs@HIDDEN</a>> writes:<br>
<br>
> The following patch fixes it, cleaning up an area of troublesome code<=
br>
> which has caused a number of recent bugs.<br>
<br>
> [2. text/x-patch; 0001-Immediately-call-status_notify-on-process-tick.=
patch]...<br>
<br>
IIUC, this is equivalent to changing a single condition here:<br>
<br>
diff --git a/src/process.c b/src/process.c<br>
index 33d96198573..7368e242c7d 100644<br>
--- a/src/process.c<br>
+++ b/src/process.c<br>
@@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &Atemp,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (num_pending_connects > 0 ? &Ctemp :=
NULL),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NULL, &timeout, NULL)<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 0))<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 0)<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| true)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* It's okay for us to=
do this and then continue with<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the loop, sin=
ce timeout has already been zeroed out.=C2=A0 */<br>
<br>
(your patch the simplified the remaining code, but maybe it's easier to=
<br>
understand if we go through the logical change first).<br></blockquote></di=
v></div><div dir=3D"auto"><br></div><div dir=3D"auto">Yes.=C2=A0</div><div =
dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_qu=
ote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
That change looks harmless, but I think it indicates something else in<br>
the code is incorrect.<br>
<br>
> Previously in wait_reading_process_output, if we saw that<br>
> update_tick !=3D process_tick, we only called status_notify if it<br>
> wasn't also some other kind of input which would cause<br>
> status_notify to be called.<br>
<br>
I'm not sure I understand this sentence. My impression is that we calle=
d<br>
status_notify in the code above if there was no input available on any<br>
of the FDs compute_input_wait_mask returned, but the other select used a<br=
>
different FD set.<br></blockquote></div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Sure sure, this sentence is describing the intention.=C2=
=A0 It mostly works but didn't quite always work due to the mask differ=
ence.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=
=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> My initial assessment of the issue is that it's caused by a differ=
ence<br>
> in the select mask calculated by the "if (update_tick !=3D proces=
s_tick)"<br>
> branch and the main select mask, which can happen when read_kbd is 0 o=
r<br>
> in various other cases.<br>
<br>
That sounds likely to me.<br>
<br>
> When these select masks are different, the "if (update_tick !=3D<=
br>
> process_tick)" branch can detect input (in this case from file-no=
tify)<br>
> which the main select will not see, causing the busy-looping behavior.=
<br>
<br>
Why are the select masks different, though?=C2=A0 Wouldn't it suffice t=
o make<br>
them the same, like this?<br></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">It would, but this code doesn't do that.=C2=A0=
</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quo=
te gmail_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
diff --git a/src/process.c b/src/process.c<br>
index 86e83e58c56..3e58ffb4a7a 100644<br>
--- a/src/process.c<br>
+++ b/src/process.c<br>
@@ -5530,6 +5530,8 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (kbd_on_hold_p ())<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FD_ZERO (&Atemp);<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else if (! read_kbd)<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compute_non_keyboard_wait_mask (&=
amp;Available);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compute_input_wait_mask (&a=
mp;Atemp);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 compute_write_mask (&Ctemp);<br></bl=
ockquote></div></div><div dir=3D"auto"></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">The mask can be computed in many other different ways too, =
if you look at the code.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>So this leaves a bunch of other potential bugs latent in the code.</div></=
div>
--0000000000001caef3064300bb5b--
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 12:34:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 07:34:34 2025
Received: from localhost ([127.0.0.1]:45649 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHLfm-0005Rr-2C
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:34:34 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:52765)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vHLfi-0005RS-Rt
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:34:32 -0500
Received: from mail-lf1-f71.google.com ([209.85.167.71])
by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128)
(Exim 4.98.2) id 1vHLfd-00000001ZKZ-0qoR for 79777 <at> debbugs.gnu.org;
Fri, 07 Nov 2025 07:34:25 -0500
Received: by mail-lf1-f71.google.com with SMTP id
2adb3069b0e04-59427acf790so440170e87.3
for <79777 <at> debbugs.gnu.org>; Fri, 07 Nov 2025 04:34:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=janestreet.com; s=google; t=1762518864; x=1763123664; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=VRiadZr4A8X1Q60UMr2deM6s/A/gIDQpimu9BjGmugs=;
b=1PiPqMdB7jFC4uMdp4gDcBZSrM399/J7ComRmd+5/qDytl+JWrHFVCMaQ1KSeADOuc
5L94GKOMhOySoiD45BAPh88++yMX/axpfjp4reUD1Pd1/U04gGvz8xULeMJ5b+qYZZ3K
qpKKm9cekzJcpkR9B5GnLxNcXL1EgpE6muWtE=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762518865;
bh=VRiadZr4A8X1Q60UMr2deM6s/A/gIDQpimu9BjGmugs=;
h=References:In-Reply-To:From:Date:Subject:To:Cc;
b=xwm4tsJ8wIO7djjPrdAPa0unK+jDlDfBjugrfWTQeNbWUKwhU/sQ4a8SIDwaAp5+Y
45NJolTlfSgtyM5QVK2y/fgUb0EwwoKf0hbg4dVyqoHDnIKiFuvGDxMXNBACv9SliZ
6v5KoqKsLLIbH7V6Uto4q3qfXsm7v64cHr3znICV7Z92oCm11xb58zvvUvDNrY4EB3
EjFfyKT0qa70HcJu2vXMG/fOMLkvm0h6qgHFkfnkhHqjchexwlM5ud9TRnFbIx9OP4
ICgN/oenugq2CViLUooD9MlgQaLNJh0LxPoEJ0141szsFOlxYh1r1ABcyYEX7FjHIc
1tH/ZZwguLr3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1762518864; x=1763123664;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=VRiadZr4A8X1Q60UMr2deM6s/A/gIDQpimu9BjGmugs=;
b=jdV/G3kIysKKBbdXM8gB9Naqz0TJWK9X+JLGX12NUWP5AcPcpMOinC27Uj09WUhthB
zO+VVxi9C9yGUtyptsAckF2140Ote0guOEOhTH319b3HYaXdQL51L7/6smd8r0vFzzf/
NFY+SJ8ISWTF2lPwf1+Ty43ubScv4ttx65tnj0SU+ATELDTSS9wqpow/9WyfolRvvL2m
ipa2GE9Hx+qi9Q8SmvcOhkKMEP/owz2Z9qn7ExdSdd4c+kZAKKH2gx8p1KffbjnvDf9U
COp3v1fQ7DmYAbBeeA4wnLN9J/R2yxiqlLTfjCPqkgefkp5Bz8mnuK55TFO8TsdSk2uj
R2ow==
X-Forwarded-Encrypted: i=1;
AJvYcCWszxbFATGu2TYq+kQ0DtUS4q6erBMpx5CvBUnVxIeohRtt79UALrtogY2XaF9iDq8uBkff7Q==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyPpkw74grzo8n2JNE/boVzBNGH/fE18+XZt2mmcqbhn/AuHFyF
PbIKyy66otA1kzo5sYrQLEV0nF5SEAqe4EAcntuM0g7k3higBg/RVOBG4N+oBPkjQH7lBG3eIIP
B/gxbd/QI0qC3RxYqmZjzLwOC8jDztb/s48efK2lGed8gKHpk3ZSmQlppUfN1YMtlMeK2OwJ/1B
u+zP7NMQZ0vnmhcdL5YEtJIxT5UApZqg==
X-Gm-Gg: ASbGncuaRQSqClSvP6WI7vg2jxI5jEX+U2ICEIYEy7Ybh2PBEjjoEwCib4vT4QNRCCM
+lU84OxN1NxGSr9uHOMGPBZHv3CptXestmcSB7pAx7qjP+YtC72GD9VdVyUKm20cq32vbROZls9
nz9yFKYD6mKdQ2321t6+cAEUczdWlXRWX43Q2DISlCuKBJF3P4bwpOf6c=
X-Received: by 2002:a05:6512:6d3:b0:57d:1082:e103 with SMTP id
2adb3069b0e04-59456b5b691mr860024e87.16.1762518863891;
Fri, 07 Nov 2025 04:34:23 -0800 (PST)
X-Google-Smtp-Source: AGHT+IG4tOcJKY/OUQvUumvPghXLUZe3fH1gSQudn9wXYDmvdSKmlwi72f0N9rnJ+gc1qGfLFJs+JGjGEx2ELHfk+bs=
X-Received: by 2002:a05:6512:6d3:b0:57d:1082:e103 with SMTP id
2adb3069b0e04-59456b5b691mr860012e87.16.1762518863421; Fri, 07 Nov 2025
04:34:23 -0800 (PST)
MIME-Version: 1.0
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<86ldki9hla.fsf@HIDDEN>
In-Reply-To: <86ldki9hla.fsf@HIDDEN>
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Fri, 7 Nov 2025 07:34:12 -0500
X-Gm-Features: AWmQ_blVzi6te1Wea-FA157tocCbcXo3fNFWSSmUwtKJEqjRqWuvjme0v0ukGq8
Message-ID: <CAO=BR8Mu2FzVpjgTiu6Kd9aO5rDEB=nvxUA42koHqRVA8=CnYA@HIDDEN>
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000c3b1c2064300667a"
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, Pip Cet <pipcet@HIDDEN>,
eggert@HIDDEN, Stefan Monnier <monnier@HIDDEN>,
79777 <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: -3.3 (---)
--000000000000c3b1c2064300667a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 7, 2025, 7:02=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote:
> > Date: Fri, 07 Nov 2025 09:00:50 +0000
> > From: Pip Cet via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> >
> > IIUC, this is equivalent to changing a single condition here:
> >
> > diff --git a/src/process.c b/src/process.c
> > index 33d96198573..7368e242c7d 100644
> > --- a/src/process.c
> > +++ b/src/process.c
> > @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit,
> int nsecs, int read_kbd,
> > &Atemp,
> > (num_pending_connects > 0 ? &Ctemp : NULL=
),
> > NULL, &timeout, NULL)
> > - <=3D 0))
> > + <=3D 0)
> > + || true)
> > {
> > /* It's okay for us to do this and then continue with
> > the loop, since timeout has already been zeroed out. =
*/
>
> That might be so, but it doesn't mean it makes sense to do this. For
> example, why should we call redisplay if there's some input available?
>
> (The original patch also removed the call to thread_select, which
> makes even less sense.)
>
> I actually don't think I understand the root cause(s) of the original
> bug. What exactly causes wait_reading_process_output loop
> indefinitely because there's a single (AFAIU) file notification?
> Also, on MS-Windows the file notifications don't work via
> pselect-testing of file descriptors, but the test case hangs anyway.
>
> I think what we see happens because sleep-for is meant to sleep
> unconditionally, and the process sentinel is only run when Emacs is
> idle (and not sleeping in sleep-for). Thus, the while loop at the end
> of the test program prevents Emacs from running the sentinel. In
> which case what we see is the expected and documented behavior, not a
> bug at all.
Nope: the bug happens just the same if the sleep-for is replaced with
accept-process-output.
I have worked closely with this code for a while now and discovered and
fixed many bugs in it. So why won't you consider my change, even though
it's not trivial? wait_reading_process_output has lots of bugs. We have
to allow it to change non-trivially to fix those bugs.
--000000000000c3b1c2064300667a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><br><div class=3D"gmail_quote gmail_quote_container" =
dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 7, 2025, 7:0=
2=E2=80=AFAM Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Date: Fri, 07 =
Nov 2025 09:00:50 +0000<br>
> From:=C2=A0 Pip Cet via "Bug reports for GNU Emacs,<br>
>=C2=A0 the Swiss army knife of text editors" <<a href=3D"mailto=
:bug-gnu-emacs@HIDDEN" target=3D"_blank" rel=3D"noreferrer">bug-gnu-emacs@=
gnu.org</a>><br>
> <br>
> IIUC, this is equivalent to changing a single condition here:<br>
> <br>
> diff --git a/src/process.c b/src/process.c<br>
> index 33d96198573..7368e242c7d 100644<br>
> --- a/src/process.c<br>
> +++ b/src/process.c<br>
> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit=
, int nsecs, int read_kbd,<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&Atemp,<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(num_pending_connects > 0 ? &am=
p;Ctemp : NULL),<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NULL, &timeout, NULL)<br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 0))<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 0)<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| true)<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* It's okay=
for us to do this and then continue with<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the loop=
, since timeout has already been zeroed out.=C2=A0 */<br>
<br>
That might be so, but it doesn't mean it makes sense to do this.=C2=A0 =
For<br>
example, why should we call redisplay if there's some input available?<=
br>
<br>
(The original patch also removed the call to thread_select, which<br>
makes even less sense.)<br>
<br>
I actually don't think I understand the root cause(s) of the original<b=
r>
bug.=C2=A0 What exactly causes wait_reading_process_output loop<br>
indefinitely because there's a single (AFAIU) file notification?<br>
Also, on MS-Windows the file notifications don't work via<br>
pselect-testing of file descriptors, but the test case hangs anyway.<br>
<br>
I think what we see happens because sleep-for is meant to sleep<br>
unconditionally, and the process sentinel is only run when Emacs is<br>
idle (and not sleeping in sleep-for).=C2=A0 Thus, the while loop at the end=
<br>
of the test program prevents Emacs from running the sentinel.=C2=A0 In<br>
which case what we see is the expected and documented behavior, not a<br>
bug at all.</blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Nope: the bug happens just the same if the sleep-for is replaced with acce=
pt-process-output.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>I have worked closely with this code for a while now and discovered and fi=
xed many bugs in it.=C2=A0 So why won't you consider my change, even th=
ough it's not trivial?=C2=A0 wait_reading_process_output has lots of bu=
gs.=C2=A0 We have to allow it to change non-trivially to fix those bugs.</d=
iv><div class=3D"gmail_quote gmail_quote_container" dir=3D"auto"></div></di=
v>
--000000000000c3b1c2064300667a--
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 12:02:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 07:02:10 2025
Received: from localhost ([127.0.0.1]:45581 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHLAP-0001Uv-LS
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:02:10 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:47482)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHLAM-0001Uc-Be
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:02:07 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vHLAD-0008Vd-Kp; Fri, 07 Nov 2025 07:01:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=WNzSDKuzUKThL/Y7CyqimaitbHs6LjOFMH/0PLbAycA=; b=IqbH233E2Qpo
X3svA7nHrQA7mAlfCjjFz26zAbrtvMs30LYZ2tjAZw1Y+RfizQt5uKmac2fj+M2oI0pjx62b50Jp1
LmUOgkjJ7rHx4PqdxK86RwVSrJ5hTxBil6TY+rIikDg4RxZOs29ilb11YIX1eA6j1XYRH3iwPNWdk
zNhD+C0KTd5r7RAxDrPhNHoPHspHx7yHzlRpZXZiCFBZQZoWxQhJcq8fXcpVf6gnZ1Wt4ZZJjq00N
hD0hUh8YOPFW9rVJkPGcg3ospyJ3yWvRATsx6TXr3PR51g6MJAQvN8IB3lUPq7vu1RywJ8swdE8tp
HpWx+VFAuYj/5a8I60TL7A==;
Date: Fri, 07 Nov 2025 14:01:53 +0200
Message-Id: <86ldki9hla.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87346qb4jo.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
dmitry@HIDDEN
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: -3.3 (---)
> Date: Fri, 07 Nov 2025 09:00:50 +0000
> From: Pip Cet via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> IIUC, this is equivalent to changing a single condition here:
>
> diff --git a/src/process.c b/src/process.c
> index 33d96198573..7368e242c7d 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
> &Atemp,
> (num_pending_connects > 0 ? &Ctemp : NULL),
> NULL, &timeout, NULL)
> - <= 0))
> + <= 0)
> + || true)
> {
> /* It's okay for us to do this and then continue with
> the loop, since timeout has already been zeroed out. */
That might be so, but it doesn't mean it makes sense to do this. For
example, why should we call redisplay if there's some input available?
(The original patch also removed the call to thread_select, which
makes even less sense.)
I actually don't think I understand the root cause(s) of the original
bug. What exactly causes wait_reading_process_output loop
indefinitely because there's a single (AFAIU) file notification?
Also, on MS-Windows the file notifications don't work via
pselect-testing of file descriptors, but the test case hangs anyway.
I think what we see happens because sleep-for is meant to sleep
unconditionally, and the process sentinel is only run when Emacs is
idle (and not sleeping in sleep-for). Thus, the while loop at the end
of the test program prevents Emacs from running the sentinel. In
which case what we see is the expected and documented behavior, not a
bug at all.
So I think there's more to this than meets the eye, and we should
understand the problem (such that it is) better before we discuss the
solutions (if they are needed).
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 09:01:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 04:01:10 2025
Received: from localhost ([127.0.0.1]:45115 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHILF-0002eu-Ju
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 04:01:09 -0500
Received: from mail-10628.protonmail.ch ([79.135.106.28]:57175)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHILA-0002eB-ET
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 04:01:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762506056; x=1762765256;
bh=rCUcPKUImVdBsQIyFH9DmSBCDGjYibj58DTSjOnICV0=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=rK6UYuXEBESXJ6Bw8Dt3ghNhEmnTO87d4F4Lsh1YWTrbC0vonCrGehGkN7MhEPq5Q
7OReyYFY2hUIcOPAgQ1u3wJwXsWyhYlBoQYQ0mQRYL9+2THy2XaunVi6Ew3AyXRc1u
/Vu6S8vLMa4atscuJQuV2fMs5iYYtW7OMMoXkLHgybMFrkZjxbsph7fKiOawXGKd07
Hv4IziRreMKRzne26oBMBWh6GiKvSeL/9MO3bNExWO08XcRIKSiFckPNObvmebKLhf
MEzNwBUQXE9zJh9dEbCNI6Ws3NJzSWeyubgwAWsS6th/elnhkbiDeV5oXpSSmKmi1z
glK4TZZyOUEBA==
Date: Fri, 07 Nov 2025 09:00:50 +0000
To: 79777 <at> debbugs.gnu.org, Spencer Baugh <sbaugh@HIDDEN>,
Dmitry Gutov <dmitry@HIDDEN>, Paul Eggert <eggert@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
Message-ID: <87346qb4jo.fsf@HIDDEN>
In-Reply-To: <ier5xbm7r9j.fsf@HIDDEN>
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 3540d4194295e236259d526d37ae84f20db63175
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
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 (-)
"Spencer Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of tex=
t editors\"" <bug-gnu-emacs@HIDDEN> writes:
> The following patch fixes it, cleaning up an area of troublesome code
> which has caused a number of recent bugs.
> [2. text/x-patch; 0001-Immediately-call-status_notify-on-process-tick.pat=
ch]...
IIUC, this is equivalent to changing a single condition here:
diff --git a/src/process.c b/src/process.c
index 33d96198573..7368e242c7d 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,
&Atemp,
(num_pending_connects > 0 ? &Ctemp : NULL),
NULL, &timeout, NULL)
- <=3D 0))
+ <=3D 0)
+ || true)
{
/* It's okay for us to do this and then continue with
the loop, since timeout has already been zeroed out. */
(your patch the simplified the remaining code, but maybe it's easier to
understand if we go through the logical change first).
That change looks harmless, but I think it indicates something else in
the code is incorrect.
> Previously in wait_reading_process_output, if we saw that
> update_tick !=3D process_tick, we only called status_notify if it
> wasn't also some other kind of input which would cause
> status_notify to be called.
I'm not sure I understand this sentence. My impression is that we called
status_notify in the code above if there was no input available on any
of the FDs compute_input_wait_mask returned, but the other select used a
different FD set.
> My initial assessment of the issue is that it's caused by a difference
> in the select mask calculated by the "if (update_tick !=3D process_tick)"
> branch and the main select mask, which can happen when read_kbd is 0 or
> in various other cases.
That sounds likely to me.
> When these select masks are different, the "if (update_tick !=3D
> process_tick)" branch can detect input (in this case from file-notify)
> which the main select will not see, causing the busy-looping behavior.
Why are the select masks different, though? Wouldn't it suffice to make
them the same, like this?
diff --git a/src/process.c b/src/process.c
index 86e83e58c56..3e58ffb4a7a 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5530,6 +5530,8 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,
=20
if (kbd_on_hold_p ())
FD_ZERO (&Atemp);
+=09 else if (! read_kbd)
+=09 compute_non_keyboard_wait_mask (&Available);
else
compute_input_wait_mask (&Atemp);
=09 compute_write_mask (&Ctemp);
That appears to fix the test case here, too, and it's a minor change (if
one that should still be documented, and the code should be cleaned up
to share code for calculating the wait masks, and we still haven't
fixed it for ttys where one "maybe_quit ()" call isn't enough, etc.).
But if a minimal change is desired, I think that two-liner might do.
Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 08:15:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 03:15:02 2025 Received: from localhost ([127.0.0.1]:44989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHHcc-0000en-GX for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 03:15:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33604) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHHca-0000e7-2S for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 03:15:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHHcU-00042r-1y; Fri, 07 Nov 2025 03:14:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=qtI3Pz+cEbIkafEQX3FU3rycu22UrSFRBcffY5i+4Pg=; b=dci4myWSiCM8 meFZl5lMoURITH10hYGt571wO1MK9Xo894wULk3wV+cTlpzkggTZPcS1c7TU1szmP8EOEkS6I3NbO nqbmeS3uMA1IdxdPT48AFFDgnzVqav6o9kJcgvrY/gREz9SH7Hi7afF2q/KHyBOlDos5zJ2P2ZGcp ieBy2vBrKTWJE5QvBwe7joyaD8e5SJEMhRWJ1YbM1EHPIu/mLP/RbPvZzsScF5u2zyCEhQ1ZXz0F4 O8NJqZtqv9jCFxixYD2eo1CI0GHgbSI44G5hNstRZMd4Bo2YOmvrIjIFPkgX86aFcclFD8AukeYNm /7aJssOYOItmAe+YElW/IQ==; Date: Fri, 07 Nov 2025 10:14:50 +0200 Message-Id: <86tsz69s3p.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ier5xbm7r9j.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: dmitry@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN 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: -3.3 (---) > Cc: Dmitry Gutov <dmitry@HIDDEN>, Paul Eggert <eggert@HIDDEN> > Date: Thu, 06 Nov 2025 17:03:36 -0500 > From: Spencer Baugh via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > The following patch fixes it, cleaning up an area of troublesome code > which has caused a number of recent bugs. Sorry, this is too radical for my palate, given the obscure bugs that the current code triggers. Please try coming up with a less drastic changes, or maybe with more specific conditions for the changes. This code is too delicate and handles too many different use cases, so only very small and localized/case-specific changes should be done in it. Thanks.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 6 Nov 2025 22:03:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 06 17:03:46 2025
Received: from localhost ([127.0.0.1]:41371 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vH853-0003hu-WB
for submit <at> debbugs.gnu.org; Thu, 06 Nov 2025 17:03:46 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:58091)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vH850-0003hm-77
for 79777 <at> debbugs.gnu.org; Thu, 06 Nov 2025 17:03:44 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: 79777 <at> debbugs.gnu.org
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
In-Reply-To: <ierseeqyjdj.fsf@HIDDEN>
(Spencer Baugh's message of "Thu, 06 Nov 2025 15:51:52 -0500")
References: <ierseeqyjdj.fsf@HIDDEN>
Date: Thu, 06 Nov 2025 17:03:36 -0500
Message-ID: <ier5xbm7r9j.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762466616;
bh=I1MCqDDlst2iAcIGuHVOxHFQeGiyUFwgm1btsQhcy58=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=eaSrq01we9uLBFuxth8ZJ6fO7yUQ5tOK3uezvCkR3KvuX78pKLPqCb+8IrqO8tSdw
Dvd49Mq5Dg3XjhMYo2XESDv5VVx41KGs/pVYMgs5kCW6JeWBj7mjv5U2YcOT+g1aNl
6uCujvRizwlLjDPh8EPWz6U9zpU6mtPlBmvtXZIB1IkoaJAPuypN6fLoyHKrJvU9BK
1QqyfuCypdijP1O78LnKHexwkY1lePx78ED04T5VtmU27hKRCO5K2f0P3kaMCrZ/kL
gQpsLxQeENeK7RbM3cXueRD2Xt8NPTK7ubQdzt40kCNk09YvDrnKDe9SJgZJKP/se2
lsZDKoX5Ifj9g==
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, Paul Eggert <eggert@HIDDEN>
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: -3.3 (---)
--=-=-=
Content-Type: text/plain
The following patch fixes it, cleaning up an area of troublesome code
which has caused a number of recent bugs.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Immediately-call-status_notify-on-process-tick.patch
From f4b0faabdd226aad03ce382ec0f967bd7c661298 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Thu, 28 Aug 2025 17:06:56 -0400
Subject: [PATCH] Immediately call status_notify on process tick
Previously in wait_reading_process_output, if we saw that
update_tick != process_tick, we only called status_notify if it
wasn't also some other kind of input which would cause
status_notify to be called.
Now, unconditionally call status_notify if update_tick !=
process_tick. This is just as good, and deletes some code which
has repeatedly been buggy for no benefit.
* src/process.c (wait_reading_process_output): Always call
status_notify on process status change. (bug#79777)
---
src/process.c | 41 +++++++----------------------------------
1 file changed, 7 insertions(+), 34 deletions(-)
diff --git a/src/process.c b/src/process.c
index a9d66555f70..6e539f4c33d 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5519,43 +5519,16 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
if (read_kbd < 0 && kbd_is_ours ())
set_waiting_for_input (&timeout);
- /* If status of something has changed, and no input is
- available, notify the user of the change right away. After
- this explicit check, we'll let the SIGCHLD handler zap
- timeout to get our attention. */
+ /* If status of something has changed, notify the user of the
+ change right away. */
if (update_tick != process_tick)
{
- fd_set Atemp;
- fd_set Ctemp;
-
- if (kbd_on_hold_p ())
- FD_ZERO (&Atemp);
- else
- compute_input_wait_mask (&Atemp);
- compute_write_mask (&Ctemp);
-
- /* If a process status has changed, the child signal pipe
- will likely be readable. We want to ignore it for now,
- because otherwise we wouldn't run into a timeout
- below. */
- int fd = child_signal_read_fd;
- eassert (fd < FD_SETSIZE);
- if (0 <= fd)
- FD_CLR (fd, &Atemp);
-
timeout = make_timespec (0, 0);
- if ((thread_select (pselect, max_desc + 1,
- &Atemp,
- (num_pending_connects > 0 ? &Ctemp : NULL),
- NULL, &timeout, NULL)
- <= 0))
- {
- /* It's okay for us to do this and then continue with
- the loop, since timeout has already been zeroed out. */
- clear_waiting_for_input ();
- got_some_output = status_notify (NULL, wait_proc);
- if (do_display) redisplay_preserve_echo_area (13);
- }
+ /* It's okay for us to do this and then continue with
+ the loop, since timeout has already been zeroed out. */
+ clear_waiting_for_input ();
+ got_some_output = status_notify (NULL, wait_proc);
+ if (do_display) redisplay_preserve_echo_area (13);
}
/* Don't wait for output from a non-running process. Just
--
2.43.7
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 6 Nov 2025 20:52:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 06 15:52:11 2025
Received: from localhost ([127.0.0.1]:40826 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vH6xm-00083W-LP
for submit <at> debbugs.gnu.org; Thu, 06 Nov 2025 15:52:11 -0500
Received: from lists.gnu.org ([2001:470:142::17]:44748)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vH6xh-00081y-4x
for submit <at> debbugs.gnu.org; Thu, 06 Nov 2025 15:52:09 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>)
id 1vH6xb-0004dF-C1
for bug-gnu-emacs@HIDDEN; Thu, 06 Nov 2025 15:51:59 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>)
id 1vH6xY-0000vv-5Y
for bug-gnu-emacs@HIDDEN; Thu, 06 Nov 2025 15:51:58 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever
X-Debbugs-Cc: Dmitry Gutov <dmitry@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Date: Thu, 06 Nov 2025 15:51:52 -0500
Message-ID: <ierseeqyjdj.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762462314;
bh=H9UzD1+EiEp8yu3iWRMT4MMCL1QlXjmiB62Fqd/QpSY=;
h=From:To:Subject:Date;
b=hqkVzIRCu/X+bv+PDqZwZxqZSqOF6eAU6q895CU2j8Ffe+2ekW73GK0IIJvv7xdBh
TZh3oVKwDn3ywrBqgb+UnvKtXwLPCtPmjmMXo0Y10+mySSr6A8JKeDu7PAiaXdPtSu
5S2KTW1x3TEq/S0oFlTQYt75u1m3BMtIPrDeBWD9mZLn7T4T8FZxd4t/hOvZ+Cs6CT
jKBbsWpMRUKHl9cPbd5hYl5TR3aE45fI7KqEmnszKJLrgxlRm3ZkhxeXjO4mwzr3Xi
qXW1Knk7yCRMdn5WFmVTDsipQa2SlQ5METwebjlsScBrFL3PFDQBe0j/FsCYhhpzKL
kxaPWeDNacmNw==
Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@HIDDEN;
helo=mxout5.mail.janestreet.com
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
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: -0.1 (/)
Run the following Lisp in emacs -Q (batch or interactive):
;; -*- lexical-binding: t; -*-
(require 'filenotify)
(defvar exited nil)
(setq myproc
(make-process
:name "proc"
:command '("sleep" ".1")
:sentinel (lambda (proc status)
(setq exited t)
(message "sentinel %s %s" proc status))))
(write-region "val1" nil "/tmp/somefile")
(file-notify-add-watch
"/tmp/somefile" '(change)
(lambda (event) (message "file-notify watch event %s" event)))
(write-region "val2" nil "/tmp/somefile")
(while (not exited)
(message "sleeping")
(sleep-for 1))
Emacs will hang forever, despite the fact that the process has exited
and the sentinel should have set "exited" to t. While it's hanging,
it's busy-looping at 100% CPU in wait_reading_process_output.
If you comment out the file-notify-add-watch, Emacs will not hang, as
expected.
My initial assessment of the issue is that it's caused by a difference
in the select mask calculated by the "if (update_tick != process_tick)"
branch and the main select mask, which can happen when read_kbd is 0 or
in various other cases.
When these select masks are different, the "if (update_tick !=
process_tick)" branch can detect input (in this case from file-notify)
which the main select will not see, causing the busy-looping behavior.
I'll work on a fix.
In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.12, Xaw scroll bars) of 2025-11-06 built on
igm-qws-u22796a
Repository revision: 75e93b831c2f3f6e58e9e21c2d1ddbd52a7cd912
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)
Configured using:
'configure --with-x-toolkit=lucid --without-gpm --without-gconf
--without-selinux --without-imagemagick --with-modules --with-gif=no
--with-cairo --with-rsvg --without-compress-install --with-tree-sitter
--enable-checking=yes,glyphs --enable-check-lisp-object-type
'CFLAGS=-O0 -g3''
Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINERAMA XINPUT2 XPM XRANDR LUCID ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-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
blink-cursor-mode: t
minibuffer-nonselected-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr compile comint ansi-osc ansi-color ring dabbrev
emacsbug lisp-mnt message mailcap yank-media puny dired dired-loaddefs
rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date subr-x mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader sendmail mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp-run
bytecomp byte-compile comp-common rx warnings icons cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
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 emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)
Memory information:
((conses 16 67987 11368) (symbols 48 6932 0) (strings 32 19206 2060)
(string-bytes 1 603186) (vectors 16 11217)
(vector-slots 8 154585 8920) (floats 8 28 8) (intervals 56 287 0)
(buffers 1064 11))
Spencer Baugh <sbaugh@HIDDEN>:dmitry@HIDDEN, eggert@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.dmitry@HIDDEN, eggert@HIDDEN, bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.