Received: (at 80110-done) by debbugs.gnu.org; 19 Jan 2026 12:18:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 19 07:18:29 2026 Received: from localhost ([127.0.0.1]:42291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vhoDE-0006jV-OH for submit <at> debbugs.gnu.org; Mon, 19 Jan 2026 07:18:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36560) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vhoDC-0006j4-3c; Mon, 19 Jan 2026 07:18: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 1vhoD5-0002eE-Vz; Mon, 19 Jan 2026 07:18:20 -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=M1CfOZWE6xHJB6fEdp4AI2MwnfA7glaGGGNdjBFlfCM=; b=ZRIcUSQgOUT21W+IAWM3 78I8rMM05Wt4PQzj5xfF9TBy2ddTJZB5Haz6XjtfbBEhC3JJBsC1qnYpjKb0p/94uQAj+iANhXlpn s69G3BVpUfmVv6T3RUjbyBi/Ex0eaAbhv7V/u6sOC1t51xj/09hSxn1BBHqkGdR3sXJH/lftAiZY7 2Qt9uV3TumbtBwEAs+/ywrlZuPx/wiJJLOBelp1jrtTzRzYr0Bd0eM2nvl2nFReNgCoQYFkvN8zzd xyDfVzcA6N1vlAlHSAM6mF8grlyacr2kZixgYRswfj4tH0fKxCYEa1N/e3NuqaBs7WPgWnlaNajEM Yqn3igcEsB2t+A==; Date: Mon, 19 Jan 2026 14:18:14 +0200 Message-Id: <86zf69n6d5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> In-Reply-To: <87ldhv0z6u.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor Doganov on Sun, 18 Jan 2026 16:31:53 +0200) Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it References: <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <aV2K9IfRz6DAQTNZ@HIDDEN> <877bttfqlb.GNU's_not_UNIX!-yavor@HIDDEN> <86tswksalt.fsf@HIDDEN> <87ldhv0z6u.GNU's_not_UNIX!-yavor@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: 80110-done Cc: alan@HIDDEN, 80110-done <at> debbugs.gnu.org, kaloian@HIDDEN, shipmints@HIDDEN, 80112-done <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 (---) > Date: Sun, 18 Jan 2026 16:31:53 +0200 > From: Yavor Doganov <yavor@HIDDEN> > Cc: Yavor Doganov <yavor@HIDDEN>, > alan@HIDDEN, > kaloian@HIDDEN, > 80112 <at> debbugs.gnu.org, > shipmints@HIDDEN > > Eli Zaretskii wrote: > > > From: Yavor Doganov <yavor@HIDDEN> > > > Alan Third wrote: > > > > I think we need to remove the test of whether the timeout is zero, > > > > because even if the timeout is zero we still need the NS runloop to > > > > run. > > > > > > This sounds logical to me; I was wondering why it is there and what is > > > its purpose. > > > So can wed now finish up this bug and bug#80110, please? Could you > > please post a patch for fixing both these bugs, as you have been using > > them, so we could review one last time before installing? > > I tested both variants of the patch (the one I asked Stéphane to test > [1] on macOS and a version with the timeout test removed as suggested > by Alan [2]). More intensive testing was done with the first > (conservative) version so this is the one I attach. Thanks, now installed, and closing these two bugs. > P.S. I feel a bit uneasy to claim authorship as setting a small > timeout was something that you suggested after Adam pointed out > that this thread_select call was being made with NULL arguments. Don't worry, the bug discussion, to which the commit log message points, has all the details.
Yavor Doganov <yavor@HIDDEN>:Eli Zaretskii <eliz@HIDDEN>:Received: (at 80110) by debbugs.gnu.org; 5 Jan 2026 15:26:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 10:26:35 2026 Received: from localhost ([127.0.0.1]:52716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcmTb-0000mZ-Dw for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 10:26:35 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55748) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vcmTY-0000mJ-Kx for 80110 <at> debbugs.gnu.org; Mon, 05 Jan 2026 10:26:33 -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 1vcmTQ-0001px-7w; Mon, 05 Jan 2026 10:26:25 -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=eat7/3wAIWXww5S5CUli9QHZRDo12akOvo8/6Ymah54=; b=XAgSx9VczEdQ 5yzVXsDCExUN6TBRSL5UpPN4fu5mFkzNUMZQnmI2teTXMfRWoK3WMaiwgbdRAGIyjl4c3xERZ0Dj6 uyVfGd4Hnx8WkHpXCxwuTiZc7yzKievOzK8FSJ+KLN6OSxgpnhdjN8Fm10il/tjFkmM4/tfxm73DD B9T7BOKGsAczJwwpGzttJyHhjJVq38a9kZo4dxXrtmuyF7sszywcrqpuEY02bTmJSmnLIa+wrLi3J efHT7eYJ/Z74DBZepByrZ2VjVeUs5GHaKWrAyKg4wyYpL2LN3wpTf6Lt8HMyHrx4gIFOYiMC97UaF qXmcUKbFNpjsRXuSfewHHQ==; Date: Mon, 05 Jan 2026 17:25:24 +0200 Message-Id: <86jyxwf5ej.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> In-Reply-To: <87ikdgt7s2.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor Doganov on Mon, 05 Jan 2026 17:10:21 +0200) Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN> <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> <86cy3snrye.fsf@HIDDEN> <87zf6wp5gt.GNU's_not_UNIX!-yavor@HIDDEN> <864ip4nq88.fsf@HIDDEN> <87344nathb.GNU's_not_UNIX!-yavor@HIDDEN> <86ikdikelf.fsf@HIDDEN> <87bjj89r8l.GNU's_not_UNIX!-yavor@HIDDEN> <86qzs4fajy.fsf@HIDDEN> <87ikdgt7s2.GNU's_not_UNIX!-yavor@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80110 Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org, alan@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: Mon, 05 Jan 2026 17:10:21 +0200 > From: Yavor Doganov <yavor@HIDDEN> > Cc: Yavor Doganov <yavor@HIDDEN>, > gerd.moellmann@HIDDEN, > 80110 <at> debbugs.gnu.org, > alan@HIDDEN > > Eli Zaretskii wrote: > > Another question: if you use this in a -nw session, do the freezes > > _never_ happen? > > That's right; the freezes never happen with -nw. I mentioned that in > my initial message. So whatever we do in the NS GUI session is definitely part of the puzzle.
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.Received: (at 80110) by debbugs.gnu.org; 5 Jan 2026 15:10:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 10:10:42 2026 Received: from localhost ([127.0.0.1]:52592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcmED-0008I6-QE for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 10:10:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38392) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vcmEB-0008Hm-EZ for 80110 <at> debbugs.gnu.org; Mon, 05 Jan 2026 10:10:40 -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 <yavor@HIDDEN>) id 1vcmE5-0006oe-AG; Mon, 05 Jan 2026 10:10:33 -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:In-Reply-To:Subject:To:From: Date; bh=soTuOmlvmfxEkYvAeYoPNfVFiOZTSVeVusvrBciCCXU=; b=R/PaHnezngsYWR6z+7qT gMH5I7V7JTUXeY/3umZUJPPNC8WcslAcw3RUXWTYvv8llrzfva2PUBpYQevS6t3RftvydlRpHgXwj TKUjDv/DaRyDk4TRaR0XSz7fUDtB5HnPpzAO+7XJFibNxeB5WcuhqpdVGHrVOkG/M3TlOc0/3kUzZ /TF4RO6wz1UShPWwHytPLoqKx+hElhMiT/W0T2WalPSaCSngJsy0SgZjt5L13asgPgBX+AAcskEau 1BROs+RhSttzw2Zoej0tTAeRxka0TzqBbX2H63o7SQzjIfZYPh0qxqMeTgdcsUfzGV5pGL7l2EBwl V72t4Bdc/E4TxA==; Date: Mon, 05 Jan 2026 17:10:21 +0200 Message-ID: <87ikdgt7s2.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep In-Reply-To: <86qzs4fajy.fsf@HIDDEN> References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN> <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> <86cy3snrye.fsf@HIDDEN> <87zf6wp5gt.GNU's_not_UNIX!-yavor@HIDDEN> <864ip4nq88.fsf@HIDDEN> <87344nathb.GNU's_not_UNIX!-yavor@HIDDEN> <86ikdikelf.fsf@HIDDEN> <87bjj89r8l.GNU's_not_UNIX!-yavor@HIDDEN> <86qzs4fajy.fsf@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80110 Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org, Yavor Doganov <yavor@HIDDEN>, alan@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 (---) Eli Zaretskii wrote: > Another question: if you use this in a -nw session, do the freezes > _never_ happen? That's right; the freezes never happen with -nw. I mentioned that in my initial message.
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.Received: (at 80110) by debbugs.gnu.org; 5 Jan 2026 13:34:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 08:34:23 2026 Received: from localhost ([127.0.0.1]:51227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vckj1-0002aj-1Z for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 08:34:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49902) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vckiy-0002aN-4L for 80110 <at> debbugs.gnu.org; Mon, 05 Jan 2026 08:34:20 -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 1vckis-0005i0-4M; Mon, 05 Jan 2026 08:34: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=8BZ2T+skQ+jtJYgclAcDvFdb8+ZzSwSqB52++3e5JUo=; b=lJuNRge3H+Se Ow1RARyyoYhsJdkVV5WkxCuAZv336P+XSX9z/ybUn+OhTzrMygUEk7J5b1Fq+n2dM5lOljEbDrOnG rwAEf1lPmKMNmXlWUdxqZlGLY7ZyD4fUEKaYhtCcNNcJyqxKHqVI9+QIWTCKhDnMZAC48TpulyYxp qqX7hJNOmE1ErFKBUN8FEi7BltnOdFyvWoHpcEe2UDRlpbvwBjHe1dFTMvUs00+MKdQMaorc/kEcO USG/Tula4CQuRw794eyjko+dYMH9QgPl1kW2ElNrhtMhyWzGumEnPamREgwdaF+dCmNBsv5/APihN K28xNAnjIPKfOeoIeiAQmg==; Date: Mon, 05 Jan 2026 15:34:09 +0200 Message-Id: <86qzs4fajy.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> In-Reply-To: <87bjj89r8l.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor Doganov on Mon, 05 Jan 2026 14:30:18 +0200) Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN> <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> <86cy3snrye.fsf@HIDDEN> <87zf6wp5gt.GNU's_not_UNIX!-yavor@HIDDEN> <864ip4nq88.fsf@HIDDEN> <87344nathb.GNU's_not_UNIX!-yavor@HIDDEN> <86ikdikelf.fsf@HIDDEN> <87bjj89r8l.GNU's_not_UNIX!-yavor@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80110 Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org, alan@HIDDEN, yavor@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: Mon, 05 Jan 2026 14:30:18 +0200 > From: Yavor Doganov <yavor@HIDDEN> > Cc: gerd.moellmann@HIDDEN, > 80110 <at> debbugs.gnu.org, > alan@HIDDEN, > yavor@HIDDEN > > On Sat, 03 Jan 2026 15:31:08 +0200, > Eli Zaretskii wrote: > > > > OK, but why there are 6 threads doing that? > > > > > > Because these threads accumulate; they are alive as the Lisp code is > > > never executed. M-x list-threads shows them as "Yielded", if I manage > > > to run this command before Emacs freezes. > > > > So Wanderlust starts another thread without checking whether a > > previous one completed? > > It seems so, yes. > > > I think "Yielded" means the thread released the global lock when it > > called thread_select to wait for the subprocess. > > I don't know about that, but the new thread never proceeds after the > acquire_global_lock call in run_thread. > > > > > Are you reading multiple messages at the same time or something? If > > > > not, why do we see more than one non-main thread running > > > > mime-verify-application-signature-internal? > > > > > > No, I'm reading one message at the time, moving immediately to the > > > next message to trigger the freeze. Apparently the freeze happened at > > > the 6th message (or the 6th signed message, I don't know) so that's > > > why we see 6 threads. > > > > How is this supposed to work from Wanderlust POV? Suppose you read a > > message, and Wanderlust then launches a thread to decode/verify it: > > what happens until the thread finishes? > > Nothing happens, I see "Veryifing..." after the MIME part containing > the signature, Emacs is not blocked so I can proceed reading the next > message or do anything else. > > > do you see the message, do you see a "in progress" indication, or > > something else? > > Yes, I see the message, it looks like the text part is being decoded > on the main thread. > > > And what should happen if you move to the next message without > > waiting for this one to be verified -- does Wanderlust stop/abort > > the verification of thye previous message? > > No, it doesn't stop or abort. I suppose that the whole idea to use > another thread in this case is not to block. If I set > mime-pgp-use-concurrency to nil, the signature verification happens on > the main thread -- I see the result of the verification but the > message is displayed with a small delay (fraction of a second). Thanks. This is a strange design, which seems to assume that a thread started to verify a message will always finish quickly enough. What if the main thread becomes busy for a prolonged period of time, thus depriving the non-main thread(s) of CPU (since only one Lisp thread can run in Emacs at any given time)? It sounds like this doesn't scale, or wasn't thought-out well enough... Another question: if you use this in a -nw session, do the freezes _never_ happen?
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.Received: (at 80110) by debbugs.gnu.org; 5 Jan 2026 12:30:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 07:30:38 2026 Received: from localhost ([127.0.0.1]:50890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcjjJ-000617-QW for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 07:30:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36638) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vcjjG-0005hQ-8P for 80110 <at> debbugs.gnu.org; Mon, 05 Jan 2026 07:30: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 <yavor@HIDDEN>) id 1vcjj8-00042m-JH; Mon, 05 Jan 2026 07:30:27 -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:In-Reply-To:Subject:To:From: Date; bh=iqz6VP5/gmTmXxJnTvtCtwT8WbLh7hPokH+f3EnxF5A=; b=AjD94L2+o1M+tfGPdMa8 ulgxGcKrscLwQVpy8qe06M2KeAIsUteB/g7GVE5XYtE8OjQkyUXiSO+RGF1+9kjLyNLIe4hpfmL81 Cb9rBwjYVQqYOhvVAJflTs1I4PlsD+UGJvphkHqxfX1fzvoxbEhts1z8q70w3g9am/4xOPhVhq8w7 8DF8p+2B3DJCmIl0IajUOlz/VnHH88YHe1L8iDSH7ynu7zQZOgt8LW2dj0+3cFbAfO8SHqMvAY6Zm O0vT40XQk9HWUe/W5aiKk0+Vq5moaV/8buPZuXKQPcIy4t4Jy1pPZ6777xAhvUH2HL6UfYQo2arWi R38G5ub+iWNK6A==; Date: Mon, 05 Jan 2026 14:30:18 +0200 Message-ID: <87bjj89r8l.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep In-Reply-To: <86ikdikelf.fsf@HIDDEN> References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN> <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> <86cy3snrye.fsf@HIDDEN> <87zf6wp5gt.GNU's_not_UNIX!-yavor@HIDDEN> <864ip4nq88.fsf@HIDDEN> <87344nathb.GNU's_not_UNIX!-yavor@HIDDEN> <86ikdikelf.fsf@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80110 Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org, alan@HIDDEN, yavor@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 (---) On Sat, 03 Jan 2026 15:31:08 +0200, Eli Zaretskii wrote: > > > OK, but why there are 6 threads doing that? > > > > Because these threads accumulate; they are alive as the Lisp code is > > never executed. M-x list-threads shows them as "Yielded", if I manage > > to run this command before Emacs freezes. > > So Wanderlust starts another thread without checking whether a > previous one completed? It seems so, yes. > I think "Yielded" means the thread released the global lock when it > called thread_select to wait for the subprocess. I don't know about that, but the new thread never proceeds after the acquire_global_lock call in run_thread. > > > Are you reading multiple messages at the same time or something? If > > > not, why do we see more than one non-main thread running > > > mime-verify-application-signature-internal? > > > > No, I'm reading one message at the time, moving immediately to the > > next message to trigger the freeze. Apparently the freeze happened at > > the 6th message (or the 6th signed message, I don't know) so that's > > why we see 6 threads. > > How is this supposed to work from Wanderlust POV? Suppose you read a > message, and Wanderlust then launches a thread to decode/verify it: > what happens until the thread finishes? Nothing happens, I see "Veryifing..." after the MIME part containing the signature, Emacs is not blocked so I can proceed reading the next message or do anything else. > do you see the message, do you see a "in progress" indication, or > something else? Yes, I see the message, it looks like the text part is being decoded on the main thread. > And what should happen if you move to the next message without > waiting for this one to be verified -- does Wanderlust stop/abort > the verification of thye previous message? No, it doesn't stop or abort. I suppose that the whole idea to use another thread in this case is not to block. If I set mime-pgp-use-concurrency to nil, the signature verification happens on the main thread -- I see the result of the verification but the message is displayed with a small delay (fraction of a second).
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.Received: (at 80110) by debbugs.gnu.org; 3 Jan 2026 13:31:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 03 08:31:19 2026 Received: from localhost ([127.0.0.1]:34463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vc1ix-0002wY-3U for submit <at> debbugs.gnu.org; Sat, 03 Jan 2026 08:31:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47288) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vc1iu-0002kC-QS for 80110 <at> debbugs.gnu.org; Sat, 03 Jan 2026 08:31:17 -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 1vc1io-0008HQ-Vt; Sat, 03 Jan 2026 08:31:11 -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=TPK5eruhskiC3cxC2wJJjkC/6rXKvuZ9miDb39e/+2I=; b=Fr6ou56Q8J8K hqY5CrRWgegoQht4AxRx3DCqx0nYBoUO2yK98yeKUXzFWJi5yFu+R3yVJBMUTpJM46BSWPb3+9SAv y33NMhu8QhcbeVca3cuYi44lX6YXAB5hUGf+5N9zL9FNu1tg+R/5Tj+U6GWJBnimeTID/PmsVvi10 ji3H4FnvUFZT8cAczV8+E28B4Nt+ynwqAtTjIsY5Dli+OTy6SWmZg0YG2FNV64NgWxyVMIHyFDFvR W1DMEdj5D4ySZBdgK2+Y8a8SYjtJkubyMBq/aLo4OU7jlXI9wBTKd8qFlZNqRSb3MmE6OSyHM/ERP zhu5CF8+PT2rFfF8iop4hg==; Date: Sat, 03 Jan 2026 15:31:08 +0200 Message-Id: <86ikdikelf.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> In-Reply-To: <87344nathb.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor Doganov on Sat, 03 Jan 2026 12:19:44 +0200) Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN> <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> <86cy3snrye.fsf@HIDDEN> <87zf6wp5gt.GNU's_not_UNIX!-yavor@HIDDEN> <864ip4nq88.fsf@HIDDEN> <87344nathb.GNU's_not_UNIX!-yavor@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80110 Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org, alan@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: Sat, 03 Jan 2026 12:19:44 +0200 > From: Yavor Doganov <yavor@HIDDEN> > Cc: gerd.moellmann@HIDDEN, > 80110 <at> debbugs.gnu.org, > alan@HIDDEN, > yavor@HIDDEN > > Eli Zaretskii wrote: > > > Wanderlust uses the SEMI library to verify the detached GPG signature > > > in a separate thread [1] if the platform supports threads (as is my > > > case). > > > > OK, but why there are 6 threads doing that? > > Because these threads accumulate; they are alive as the Lisp code is > never executed. M-x list-threads shows them as "Yielded", if I manage > to run this command before Emacs freezes. So Wanderlust starts another thread without checking whether a previous one completed? I think "Yielded" means the thread released the global lock when it called thread_select to wait for the subprocess. > > Are you reading multiple messages at the same time or something? If > > not, why do we see more than one non-main thread running > > mime-verify-application-signature-internal? > > No, I'm reading one message at the time, moving immediately to the > next message to trigger the freeze. Apparently the freeze happened at > the 6th message (or the 6th signed message, I don't know) so that's > why we see 6 threads. How is this supposed to work from Wanderlust POV? Suppose you read a message, and Wanderlust then launches a thread to decode/verify it: what happens until the thread finishes? do you see the message, do you see a "in progress" indication, or something else? And what should happen if you move to the next message without waiting for this one to be verified -- does Wanderlust stop/abort the verification of thye previous message?
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.Received: (at 80110) by debbugs.gnu.org; 3 Jan 2026 10:20:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 03 05:20:00 2026 Received: from localhost ([127.0.0.1]:33707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vbyjo-0003m0-FF for submit <at> debbugs.gnu.org; Sat, 03 Jan 2026 05:20:00 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43916) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vbyjm-0003lc-Hg for 80110 <at> debbugs.gnu.org; Sat, 03 Jan 2026 05:19:58 -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 <yavor@HIDDEN>) id 1vbyjg-0000z2-6v; Sat, 03 Jan 2026 05:19:52 -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:In-Reply-To:Subject:To:From: Date; bh=WwiYFc1xcwseJcZ3BVipn87DuxBFFc3BXVcUPn+7N7k=; b=kBjev0+vT3VWSW9I+Zw8 GqMywAd7h6alHKLO+RCvFURqK7R9fdbqDWWKZ8jgIkwVdNPG4YIDPij2WnheuBA8WVl50vYHxwKgg BpyLoKgp5sreAimSMwOxjECc8lWLgnRKsld0MBRSO/pUvzLNxD0NabPBisJNG7/e1mmISKwdrWS8K yciEAzv9WYiQkzKDGLWuoHVorKHsyozw9i+Sfkqw5arjnStJN39DtFxdmpxf/HxVvnctGsiiXOnU1 auAuMDmxv5LqGoqyhO4FiNZ1O09LlZTw0Ix3PMU5LiFZlGBsUSaMSRoJy8XF5VDkuOAVjoFEnLsGX gLIKLmZCl/3IRQ==; Date: Sat, 03 Jan 2026 12:19:44 +0200 Message-ID: <87344nathb.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep In-Reply-To: <864ip4nq88.fsf@HIDDEN> References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN> <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> <86cy3snrye.fsf@HIDDEN> <87zf6wp5gt.GNU's_not_UNIX!-yavor@HIDDEN> <864ip4nq88.fsf@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80110 Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org, alan@HIDDEN, yavor@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 (---) Eli Zaretskii wrote: > > Wanderlust uses the SEMI library to verify the detached GPG signature > > in a separate thread [1] if the platform supports threads (as is my > > case). > > OK, but why there are 6 threads doing that? Because these threads accumulate; they are alive as the Lisp code is never executed. M-x list-threads shows them as "Yielded", if I manage to run this command before Emacs freezes. > Are you reading multiple messages at the same time or something? If > not, why do we see more than one non-main thread running > mime-verify-application-signature-internal? No, I'm reading one message at the time, moving immediately to the next message to trigger the freeze. Apparently the freeze happened at the 6th message (or the 6th signed message, I don't know) so that's why we see 6 threads.
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.Received: (at 80110) by debbugs.gnu.org; 2 Jan 2026 12:40:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 07:40:23 2026 Received: from localhost ([127.0.0.1]:56695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vbeS6-0004qe-Qf for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:40:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39068) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vbeS4-0004mg-5B for 80110 <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:40:20 -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 1vbeRy-0006Z5-BJ; Fri, 02 Jan 2026 07:40: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=2P5lsUGdeevDHrApChe2lNvT1hm/yQPCHYSVU9pRqz4=; b=U9UEyj8wkyIK lLgwozhDFkogac4t/sldK/NLF433HN49t4rdd7XKsQihKiQWLaCwdWAdXtDrWg4Q1Yz1/bF17oiOH SKwkGHg/RfHIzd6AMwxrLoIYXkeJHRGhV39XDrij17aXms19dW/edQlvQ8+t1YhARaKjzbA992nIl yCTvbBLzzrbhQq01NjWTefUmzOFRK57sALE4zEjEEqtoX0Y9vlC0NP+8T1NRJ7IqXdTvhb+IDZx6x CgCxSy5719NagZQu3hVluFxXsKytOxLWzrFtEywtcst1wmAgT70PbjQ1FKzVgZw4YLyDw+d4tRpx+ UGjvV93+9M7lWyTVJoQoUg==; Date: Fri, 02 Jan 2026 14:39:19 +0200 Message-Id: <864ip4nq88.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> In-Reply-To: <87zf6wp5gt.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor Doganov on Fri, 02 Jan 2026 14:24:50 +0200) Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN> <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> <86cy3snrye.fsf@HIDDEN> <87zf6wp5gt.GNU's_not_UNIX!-yavor@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80110 Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org, alan@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, 02 Jan 2026 14:24:50 +0200 > From: Yavor Doganov <yavor@HIDDEN> > Cc: gerd.moellmann@HIDDEN, > 80110 <at> debbugs.gnu.org, > alan@HIDDEN, yavor@HIDDEN > > Eli Zaretskii wrote: > > Why so many of the non-main threads (6, if my count is correct) in the > > backtrace seem to be calling the same function, > > mime-verify-application-signature-internal? Does this make sense when > > using Wanderlust the way you were using it? > > Yes, I think it makes sense. I reported Bug#80112 (which may or may > not be related to this bug) because of this. > > Wanderlust uses the SEMI library to verify the detached GPG signature > in a separate thread [1] if the platform supports threads (as is my > case). OK, but why there are 6 threads doing that? Are you reading multiple messages at the same time or something? If not, why do we see more than one non-main thread running mime-verify-application-signature-internal? > while it should read "Good signature from ..." or "Missing public > key...", "Bad signature..." , etc. Apparently the many threads are > the result of reading many GPG-signed messages (for which make-thread > created new threads to verify the signatures). How come Wanderlust needs to verify more that a single GPG-signed message at the same time? (I know nothing about Wanderlust, so apologies for asking these questions.)
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.Received: (at 80110) by debbugs.gnu.org; 2 Jan 2026 12:25:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 07:25:08 2026 Received: from localhost ([127.0.0.1]:56640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vbeDL-0001Cx-S2 for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:25:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59840) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vbeDK-0001CO-2N for 80110 <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:25:06 -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 <yavor@HIDDEN>) id 1vbeDD-0003pS-Ic; Fri, 02 Jan 2026 07:24:59 -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:In-Reply-To:Subject:To:From: Date; bh=tvByF3sWMnPEGQ1Ef3VlIv2oxLndy9I/IK4eFLl9NFM=; b=mTazODwlyT330eDhatFv fvQybKKLC4+Yhsdl0IXhWlHfupLtf7Vn4kGU1kF1hiOch5IrV219vrDn5W2uUFab06DLq27G4L0a2 DPo9sWiG6ARV8mzBdxWPaYsu8hH1M9trCj8cVEJwMx/T8885C8C2AuNuP2REdOqo2MbzWhOjbsQvW 9Z9kmz8PrkDGvO5RbicYcG5okFua4mr4xNBh3XAArRz9LNvW0DUmywRFLf48BLcG31uPdqKRwkgc/ UE1yyXLXuxf0qcOVgD2ibStDhOwbu/iHhts8VgM5osprHXH9P1t3E06Cc+LNS4d4I/FXw4LLeOhLY 2EyQf5ooVhJvuw==; Date: Fri, 02 Jan 2026 14:24:50 +0200 Message-ID: <87zf6wp5gt.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep In-Reply-To: <86cy3snrye.fsf@HIDDEN> References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN> <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> <86cy3snrye.fsf@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80110 Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org, alan@HIDDEN, yavor@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 (---) Eli Zaretskii wrote: > > That is a good question. I think the answer is that there are several > > threads and Emacs is being stuck somewhere, > > Why so many of the non-main threads (6, if my count is correct) in the > backtrace seem to be calling the same function, > mime-verify-application-signature-internal? Does this make sense when > using Wanderlust the way you were using it? Yes, I think it makes sense. I reported Bug#80112 (which may or may not be related to this bug) because of this. Wanderlust uses the SEMI library to verify the detached GPG signature in a separate thread [1] if the platform supports threads (as is my case). With the NS port, I see [2 signature.asc <application/pgp-signature (7bit)>] Verifying... while it should read "Good signature from ..." or "Missing public key...", "Bad signature..." , etc. Apparently the many threads are the result of reading many GPG-signed messages (for which make-thread created new threads to verify the signatures). If I start Emacs with -nw or use another flavor (GTK or Lucid), I never see this "Verifying..." message because execution of this function happens very quickly so the text is being immediately replaced by the result of the function. [1] https://sources.debian.org/src/semi/1.14.7~0.20230104-1/mime-pgp.el#L221
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.Received: (at 80110) by debbugs.gnu.org; 2 Jan 2026 12:02:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 07:02:20 2026 Received: from localhost ([127.0.0.1]:56558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vbdrI-0008WS-EL for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:02:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43038) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vbdrE-0008W5-TQ for 80110 <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:02:18 -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 1vbdr8-0007Gx-Km; Fri, 02 Jan 2026 07:02:10 -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=+C/DY2WV2vDRByszYoV0WYrHg3pPw4ttQeZ3G5ORmRo=; b=CQN7iD/0SW6H Ws7ame9TFUdGUUD02HXMnuqwwxcqzkR5CSUPNZo7P6qjWduQkl5ykGJ+1lzH8jOohvN2BqfU61tQb vxVGgxHThTfXftCXChMwYVLoC+1uvm7M1SCuSShV4ZoFIdwV7AeQttw4a6tw1Pt/FTXU/9u2iPktR 3txQWfyQPX250BEgSFYrP6DpxJLHij6+eGQXZsOo6udJ+nd9+vzfZsc8i2oT84K/zFF7Q1ZPjPBT5 ym76K97vC/ad7ez3ohGfO5oIIorw8vJdOobYvJGIwEFi5XB20Ye3F+OE9WH3eNFQf4ZH04IBi0ALq hOFOS14b2rUvr6fQfwfHCg==; Date: Fri, 02 Jan 2026 14:02:01 +0200 Message-Id: <86cy3snrye.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> In-Reply-To: <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor Doganov on Fri, 02 Jan 2026 12:39:24 +0200) Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN> <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80110 Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org, alan@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, 02 Jan 2026 12:39:24 +0200 > From: Yavor Doganov <yavor@HIDDEN> > Cc: gerd.moellmann@HIDDEN, > 80110 <at> debbugs.gnu.org, > Alan Third <alan@HIDDEN>, Yavor Doganov <yavor@HIDDEN> > > > (I don't doubt your expertise in GNUstep, > > I am not a GNUstep expert at all, just a long-time user. That's more that most of all of us here can say. Moreover, you seem to have dug into the Emacs internals on that platform, so, at least for me, you are an expert of sorts. > > what does NS_IMPL_GNUSTEP mean, when it is true and when false? IOW, > > which configurations and builds of Emacs is it supposed to affect? > > It is true when Emacs is configured --with-ns and the system is not > macOS. IOW, Emacs uses the GNUstep implementation on all other > systems (GNU/Linux, Windows, Solaris, etc.). On macOS, NS_IMPL_COCOA > is true. (NS_IMPL_GNUSTEP and NS_IMPL_COCOA are mutually exclusive.) > > These are described briefly in admin/CPP-DEFINES. Thanks for mentioning CPP-DEFINES. In this case, it fails to mention that NS_IMPL_GNUSTEP is only true on systems other than macOS (and NS_IMPL_COCOA has a similar problem). > > if so, I'm not sure how reverting Gerd's changes would have solved > > this, since AFAICT the freeze is inside this call of thread_select: > > > > if (![NSThread isMainThread] > > || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0)) > > thread_select (pselect, nfds, readfds, writefds, <<<<<<<<<<<<<<<<<<<< > > exceptfds, timeout, sigmask); > > else > > > > and Gerd's change just prevented the code from returning right after > > thread_select returns. But if thread_select doesn't return, how would > > reverting that help? Or what am I missing? > > That is a good question. I think the answer is that there are several > threads and Emacs is being stuck somewhere, probably blocked by the > GNUstep event loop. Here is the backtrace from all threads from yet > another freeze (again, SIGSTOP was sent with "kill -s" to the Emacs > process). Why so many of the non-main threads (6, if my count is correct) in the backtrace seem to be calling the same function, mime-verify-application-signature-internal? Does this make sense when using Wanderlust the way you were using it?
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.Received: (at 80110) by debbugs.gnu.org; 2 Jan 2026 11:28:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 06:28:29 2026 Received: from localhost ([127.0.0.1]:56484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vbdKX-0006oh-0p for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 06:28:29 -0500 Received: from dane.soverin.net ([2a10:de80:1:4091:b9e9:222f:0:1]:45213) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <alan@HIDDEN>) id 1vbdKU-0006oL-D9 for 80110 <at> debbugs.gnu.org; Fri, 02 Jan 2026 06:28:27 -0500 Received: from smtp.soverin.net (unknown [10.10.4.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4djLzS3B0yz1H23; Fri, 02 Jan 2026 11:28:20 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4djLzR6GtyzHs; Fri, 2 Jan 2026 11:28:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1767353300; bh=VfwGxEiIVlYTW7ooMYJywFStNmar5eiOWERenQoNK3Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HvyXBGx2Un7AvL16TtIVTLlwbb5hW9Se/DSFf7psD6DXXYmJfwtnaQ2NT1BM6CnrY tKHTassfrQEApli/cEh0uqKf9Uc3IUn4MS5+KXNZ4qBgyBJP7DJYxjRvERoH683blf l/ofBm94+hUDN8rda9GOZF5YVlj4AdyMvQJzLZsuB42Mr27D3jAP4tmYebRhjpcdQ7 ucLeY30uMKzoP9nAwWYAOvkhjndVTRsljp9JLFqQGOfPvVO58KKf9HJN0vTcW3kI/4 tbKjCT2LnYWgmqpdL6VV6iknt6rL/MadTfXPViSTQNXqzG1mNZYLBPcjp9hjt8OTFY QQBLEim4rJnpg== X-CM-Envelope: MS4xfBmr513i//1b/vMljsHQ3RX9f2aC7KkPEHXd/pyXAcslUJZoKdva0L/D5TcyZX/MoVAa+abo3oF0M0J+zWQhImf7vrf1VOFJMimJZK9q+nnuwkx9tS0L e9dF/q4PqPxaYbbz7rPcmwCf4jJzIoIuUQfvMSF6TLGGlPTTyoW6BxHaZ0V4oqOJgQa+KNl/Fc22eMPi2OsNo6+EZ/7bb4gHecRQnVNSEo3gd18k+mOIK3SA xIGz12Ypssg7eObiS+mOkeQ7FF5hqFeeqEpmPAIo2y4= X-Soverin-Id: 019b7e77-3420-7719-9742-bbbaa837b751 Received: from localhost (namib.holly.idiocy.org [local]) by namib.holly.idiocy.org (OpenSMTPD) with ESMTPA id 30486721; Fri, 2 Jan 2026 11:28:18 +0000 (UTC) Date: Fri, 2 Jan 2026 11:28:18 +0000 From: Alan Third <alan@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep Message-ID: <aVer0rOAsVvURduW@HIDDEN> Mail-Followup-To: Alan Third <alan@HIDDEN>, Yavor Doganov <yavor@HIDDEN>, 80110 <at> debbugs.gnu.org References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> X-Spampanel-Class: ham X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80110 Cc: 80110 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Fri, Jan 02, 2026 at 08:58:24AM +0200, Yavor Doganov wrote: > This is a reincarnation of Bug#69561 but it happens on GNU/Linux. > It is fairly easy to reproduce with my MUA Wanderlust -- I am not able > to read more than a few mails or Usenet articles. It happened also > with ERC and TRAMP and I bet it can be reproduced with Gnus as well. > > Partially reverting Gerd Möllmann's commit 4ac4cec fixes the problem > immediately. I admit I don't understand the code well and cannot > figure out why execution should proceed further instead of simply > returning thread_select as before that change. The freezes always > happen on the main thread, when the second condition is true: > > (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0) > > And if this is not the main thread, it seems wrong to call [NSApp run]. I agree. I never really understood the consequences of Gerd's change here but it seemed wrong to me. Although he *had* identified a real problem and this did fix it for him. I suspect most of the time we're seeing problems with this code is when Emacs is using threads and the NS code doesn't really work with them. It works on a very basic level, but is prone to crashing, etc. because it wasn't designed with that use in mind. I don't know what the correct thing to do here is (excepting a rewrite). -- Alan Third
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.
Received: (at 80110) by debbugs.gnu.org; 2 Jan 2026 10:40:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 05:40:22 2026
Received: from localhost ([127.0.0.1]:56344 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vbcZv-0004Yu-Sg
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 05:40:22 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:50310)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vbcZr-0004WD-UG
for 80110 <at> debbugs.gnu.org; Fri, 02 Jan 2026 05:40:18 -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 <yavor@HIDDEN>)
id 1vbcZl-0007Or-N5; Fri, 02 Jan 2026 05:40:09 -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:In-Reply-To:Subject:To:From:
Date; bh=88cvwEYPcbIyc7B+YqxbFE6Yy4iPfRW6066JZ5InUBE=; b=e/Aw6HXaRtnVvQGj1VXY
FdRx2+aSlkONr0w+MhlJDtrOCFAZcfv6DoqHv2KYp2XpwjutXhpadgsuDXRSSqgcIuYIsGFpkyX07
lyLAOu6+tM/B9KVKa8cCUJOyzlOQbbN5MJkKcWQ82oQoQPUQh16FtvNvHt1YtAHFLuRHkJI7gWxDG
dTd6vsGw6pnhWHEEj42H+l4zfR2K+9kDY8Y8BNPzqzZqoXBGAj+qC9LXyYHP9PYcTS+HqtNfi7a8i
ObJz9ktUrZXwV/EU0N8ZsEJZgy9mH/pLhfYAPULIrdvlgVIso0ere4EUgoNY1MCNW3go4rDtXhUla
daO6QiZUlRQBMQ==;
Date: Fri, 02 Jan 2026 12:39:24 +0200
Message-ID: <87344oqowz.GNU's_not_UNIX!-yavor@HIDDEN>
From: Yavor Doganov <yavor@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep
In-Reply-To: <86jyy0o3fq.fsf@HIDDEN>
References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> <86jyy0o3fq.fsf@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2
(x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80110
Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org,
Alan Third <alan@HIDDEN>, Yavor Doganov <yavor@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 (---)
Eli Zaretskii wrote:
> The amount of NS expertise in our team is very limited, to put it
> mildly, so please always explain in detail the meaning and intended
> effects of the various NS-related conditions, otherwise it is very
> hard for us to review your patches and provide meaningful feedback.
Apologies.
> (I don't doubt your expertise in GNUstep,
I am not a GNUstep expert at all, just a long-time user.
> > --- a/src/nsterm.m
> > +++ b/src/nsterm.m
> > @@ -5073,6 +5073,9 @@ Function modeled after x_draw_glyph_string_box ().
> >
> > if (![NSThread isMainThread]
> > || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
> > +#ifdef NS_IMPL_GNUSTEP
> > + return
> > +#endif
> > thread_select (pselect, nfds, readfds, writefds,
> > exceptfds, timeout, sigmask);
>
> what does NS_IMPL_GNUSTEP mean, when it is true and when false? IOW,
> which configurations and builds of Emacs is it supposed to affect?
It is true when Emacs is configured --with-ns and the system is not
macOS. IOW, Emacs uses the GNUstep implementation on all other
systems (GNU/Linux, Windows, Solaris, etc.). On macOS, NS_IMPL_COCOA
is true. (NS_IMPL_GNUSTEP and NS_IMPL_COCOA are mutually exclusive.)
These are described briefly in admin/CPP-DEFINES.
> > @@ -5213,7 +5216,7 @@ Function modeled after x_draw_glyph_string_box ().
> > NSTRACE_WHEN (NSTRACE_GROUP_EVENTS, "ns_run_loop_break");
> >
> > /* If we don't have a GUI, don't send the event. */
> > - if (NSApp != NULL)
> > + if (NSApp != nil)
> > ns_send_appdefined(-1);
>
> Is this a typo fix? If not, please tell the difference between NULL
> and nil in thyis context, and its significance.
Yes, this is a typo fix and I seriously doubt it has any influence
(it's just one of the first things I saw and so it remained in my
patch).
> As for this backtrace:
>
> > (gdb) bt
> > #0 futex_wait (futex_word=0x5555559c3c20 <global_lock>, expected=2, private=0)
> > at ../sysdeps/nptl/futex-internal.h:146
> > [...]
> please tell when it was taken. Was this taken when Emacs froze?
Sorry, I should have mentioned this. It was taken when Emacs froze
and I sent SIGSTOP to the Emacs process so that I can get the gdb
prompt.
> if so, I'm not sure how reverting Gerd's changes would have solved
> this, since AFAICT the freeze is inside this call of thread_select:
>
> if (![NSThread isMainThread]
> || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
> thread_select (pselect, nfds, readfds, writefds, <<<<<<<<<<<<<<<<<<<<
> exceptfds, timeout, sigmask);
> else
>
> and Gerd's change just prevented the code from returning right after
> thread_select returns. But if thread_select doesn't return, how would
> reverting that help? Or what am I missing?
That is a good question. I think the answer is that there are several
threads and Emacs is being stuck somewhere, probably blocked by the
GNUstep event loop. Here is the backtrace from all threads from yet
another freeze (again, SIGSTOP was sent with "kill -s" to the Emacs
process).
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7fffeebe4240 (LWP 2299551) "emacs" futex_wait (
futex_word=0x5555559c3c20 <global_lock>, expected=2, private=0)
at ../sysdeps/nptl/futex-internal.h:146
2 Thread 0x7fffe9a446c0 (LWP 2299558) "emacs" __syscall_cancel_arch
() at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
3 Thread 0x7fffe25ff6c0 (LWP 2299565) "pool-spawner" syscall ()
at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
4 Thread 0x7fffe1dfe6c0 (LWP 2299566) "gmain" __syscall_cancel_arch
() at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
5 Thread 0x7fffe15fd6c0 (LWP 2299567) "gdbus" __syscall_cancel_arch
() at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
9 Thread 0x7fffd37fe6c0 (LWP 2299586) "emacs" __syscall_cancel_arch
() at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
12 Thread 0x7fffd13f86c0 (LWP 2299590) "emacs" __syscall_cancel_arch
() at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
14 Thread 0x7fffb77fe6c0 (LWP 2299592) "emacs" __syscall_cancel_arch
() at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
16 Thread 0x7fffb5ffa6c0 (LWP 2299595) "emacs" __syscall_cancel_arch
() at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
22 Thread 0x7fff9d3f86c0 (LWP 2299602) "emacs" __syscall_cancel_arch
() at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
23 Thread 0x7fff87fff6c0 (LWP 2299603) "emacs" __syscall_cancel_arch
() at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
(gdb) thread apply all bt
Thread 23 (Thread 0x7fff87fff6c0 (LWP 2299603) "emacs"):
#0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1 0x00007ffff2e91e44 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=4294967295, nr=202) at ./nptl/cancellation.c:49
#2 0x00007ffff2e9245c in __futex_abstimed_wait_common64 (private=0, futex_word=0x5555571bbae0, expected=<optimized out>, op=<optimized out>, abstime=0x0, cancel=true) at ./nptl/futex-internal.c:57
#3 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
#4 0x00007ffff2e924bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#5 0x00007ffff2e949c8 in __pthread_cond_wait_common (cond=0x5555571bbac0, mutex=0x5555559c3c20 <global_lock>, clockid=0, abstime=0x0) at ./nptl/pthread_cond_wait.c:421
#6 ___pthread_cond_wait (cond=cond@entry=0x5555571bbac0, mutex=mutex@entry=0x5555559c3c20 <global_lock>) at ./nptl/pthread_cond_wait.c:453
#7 0x00005555557efc85 in sys_cond_wait (sys_cond=sys_cond@entry=0x5555571bbac0, sys_mutex=sys_mutex@entry=0x5555559c3c20 <global_lock>) at ../../src/systhread.c:172
#8 0x00005555557ee9bf in lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x55555cd55390, new_count=0) at ../../src/thread.c:234
#9 lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x55555cd55390, new_count=0) at ../../src/thread.c:212
#10 0x00005555557eeb36 in lisp_mutex_lock (mutex=<optimized out>, new_count=0) at ../../src/thread.c:249
#11 mutex_lock_callback (arg=<optimized out>) at ../../src/thread.c:339
#12 0x00005555557ee7e5 in flush_stack_call_func (func=0x5555557eeb20 <mutex_lock_callback>, arg=0x5555571bbaa0) at ../../src/lisp.h:4476
#13 Fmutex_lock (mutex=0x5555571bbaa5) at ../../src/thread.c:367
#14 0x00007fffe8dba0a3 in F6d696d652d7665726966792d6170706c69636174696f6e2f2a2d7369676e61747572652d696e7465726e616c_mime_verify_application_signature_internal_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/mime-pgp-321fbc8b-2f8a3100.eln
#15 0x0000555555767124 in eval_sub (form=form@entry=0x55555cee9da3) at ../../src/eval.c:2670
#16 0x0000555555769c1f in internal_lisp_condition_case (var=<optimized out>, bodyform=0x55555cee9da3, handlers=<optimized out>) at ../../src/eval.c:1617
#17 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#18 0x0000555555769dac in Flet (args=0x55555cee9c13) at ../../src/eval.c:1164
#19 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#20 0x0000555555767e00 in Fprogn (body=<optimized out>) at ../../src/eval.c:445
#21 funcall_lambda (fun=<optimized out>, nargs=<optimized out>, arg_vector=<optimized out>) at ../../src/eval.c:3421
#22 0x0000555555768295 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fff87ffe318) at ../../src/eval.c:3177
#23 0x00005555557ee6b0 in invoke_thread_function () at ../../src/thread.c:747
#24 0x00005555557633a4 in internal_condition_case (bfun=bfun@entry=0x5555557ee680 <invoke_thread_function>, handlers=handlers@entry=0x30, hfun=hfun@entry=0x5555557ee550 <record_thread_error>) at ../../src/eval.c:1690
#25 0x00005555557eef0a in run_thread (state=0x55555cd55390) at ../../src/thread.c:818
#26 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#27 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 22 (Thread 0x7fff9d3f86c0 (LWP 2299602) "emacs"):
#0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1 0x00007ffff2e91e44 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=4294967295, nr=202) at ./nptl/cancellation.c:49
#2 0x00007ffff2e9245c in __futex_abstimed_wait_common64 (private=0, futex_word=0x5555571bbae0, expected=<optimized out>, op=<optimized out>, abstime=0x0, cancel=true) at ./nptl/futex-internal.c:57
#3 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
#4 0x00007ffff2e924bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#5 0x00007ffff2e949c8 in __pthread_cond_wait_common (cond=0x5555571bbac0, mutex=0x5555559c3c20 <global_lock>, clockid=0, abstime=0x0) at ./nptl/pthread_cond_wait.c:421
#6 ___pthread_cond_wait (cond=cond@entry=0x5555571bbac0, mutex=mutex@entry=0x5555559c3c20 <global_lock>) at ./nptl/pthread_cond_wait.c:453
#7 0x00005555557efc85 in sys_cond_wait (sys_cond=sys_cond@entry=0x5555571bbac0, sys_mutex=sys_mutex@entry=0x5555559c3c20 <global_lock>) at ../../src/systhread.c:172
#8 0x00005555557ee9bf in lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x55555cca0ae0, new_count=0) at ../../src/thread.c:234
#9 lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x55555cca0ae0, new_count=0) at ../../src/thread.c:212
#10 0x00005555557eeb36 in lisp_mutex_lock (mutex=<optimized out>, new_count=0) at ../../src/thread.c:249
#11 mutex_lock_callback (arg=<optimized out>) at ../../src/thread.c:339
#12 0x00005555557ee7e5 in flush_stack_call_func (func=0x5555557eeb20 <mutex_lock_callback>, arg=0x5555571bbaa0) at ../../src/lisp.h:4476
#13 Fmutex_lock (mutex=0x5555571bbaa5) at ../../src/thread.c:367
#14 0x00007fffe8dba0a3 in F6d696d652d7665726966792d6170706c69636174696f6e2f2a2d7369676e61747572652d696e7465726e616c_mime_verify_application_signature_internal_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/mime-pgp-321fbc8b-2f8a3100.eln
#15 0x0000555555767124 in eval_sub (form=form@entry=0x55555cef0823) at ../../src/eval.c:2670
#16 0x0000555555769c1f in internal_lisp_condition_case (var=<optimized out>, bodyform=0x55555cef0823, handlers=<optimized out>) at ../../src/eval.c:1617
#17 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#18 0x0000555555769dac in Flet (args=0x55555cef05f3) at ../../src/eval.c:1164
#19 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#20 0x0000555555767e00 in Fprogn (body=<optimized out>) at ../../src/eval.c:445
#21 funcall_lambda (fun=<optimized out>, nargs=<optimized out>, arg_vector=<optimized out>) at ../../src/eval.c:3421
#22 0x0000555555768295 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fff9d3f7318) at ../../src/eval.c:3177
#23 0x00005555557ee6b0 in invoke_thread_function () at ../../src/thread.c:747
#24 0x00005555557633a4 in internal_condition_case (bfun=bfun@entry=0x5555557ee680 <invoke_thread_function>, handlers=handlers@entry=0x30, hfun=hfun@entry=0x5555557ee550 <record_thread_error>) at ../../src/eval.c:1690
#25 0x00005555557eef0a in run_thread (state=0x55555cca0ae0) at ../../src/thread.c:818
#26 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#27 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 16 (Thread 0x7fffb5ffa6c0 (LWP 2299595) "emacs"):
#0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1 0x00007ffff2e91e44 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=4294967295, nr=202) at ./nptl/cancellation.c:49
#2 0x00007ffff2e9245c in __futex_abstimed_wait_common64 (private=0, futex_word=0x5555571bbae0, expected=<optimized out>, op=<optimized out>, abstime=0x0, cancel=true) at ./nptl/futex-internal.c:57
#3 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
#4 0x00007ffff2e924bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#5 0x00007ffff2e949c8 in __pthread_cond_wait_common (cond=0x5555571bbac0, mutex=0x5555559c3c20 <global_lock>, clockid=0, abstime=0x0) at ./nptl/pthread_cond_wait.c:421
#6 ___pthread_cond_wait (cond=cond@entry=0x5555571bbac0, mutex=mutex@entry=0x5555559c3c20 <global_lock>) at ./nptl/pthread_cond_wait.c:453
#7 0x00005555557efc85 in sys_cond_wait (sys_cond=sys_cond@entry=0x5555571bbac0, sys_mutex=sys_mutex@entry=0x5555559c3c20 <global_lock>) at ../../src/systhread.c:172
#8 0x00005555557ee9bf in lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x555556ec7760, new_count=0) at ../../src/thread.c:234
#9 lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x555556ec7760, new_count=0) at ../../src/thread.c:212
#10 0x00005555557eeb36 in lisp_mutex_lock (mutex=<optimized out>, new_count=0) at ../../src/thread.c:249
#11 mutex_lock_callback (arg=<optimized out>) at ../../src/thread.c:339
#12 0x00005555557ee7e5 in flush_stack_call_func (func=0x5555557eeb20 <mutex_lock_callback>, arg=0x5555571bbaa0) at ../../src/lisp.h:4476
#13 Fmutex_lock (mutex=0x5555571bbaa5) at ../../src/thread.c:367
#14 0x00007fffe8dba0a3 in F6d696d652d7665726966792d6170706c69636174696f6e2f2a2d7369676e61747572652d696e7465726e616c_mime_verify_application_signature_internal_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/mime-pgp-321fbc8b-2f8a3100.eln
#15 0x0000555555767124 in eval_sub (form=form@entry=0x55555cd48173) at ../../src/eval.c:2670
#16 0x0000555555769c1f in internal_lisp_condition_case (var=<optimized out>, bodyform=0x55555cd48173, handlers=<optimized out>) at ../../src/eval.c:1617
#17 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#18 0x0000555555769dac in Flet (args=0x55555cd4fa03) at ../../src/eval.c:1164
#19 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#20 0x0000555555767e00 in Fprogn (body=<optimized out>) at ../../src/eval.c:445
#21 funcall_lambda (fun=<optimized out>, nargs=<optimized out>, arg_vector=<optimized out>) at ../../src/eval.c:3421
#22 0x0000555555768295 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffb5ff9318) at ../../src/eval.c:3177
#23 0x00005555557ee6b0 in invoke_thread_function () at ../../src/thread.c:747
#24 0x00005555557633a4 in internal_condition_case (bfun=bfun@entry=0x5555557ee680 <invoke_thread_function>, handlers=handlers@entry=0x30, hfun=hfun@entry=0x5555557ee550 <record_thread_error>) at ../../src/eval.c:1690
#25 0x00005555557eef0a in run_thread (state=0x555556ec7760) at ../../src/thread.c:818
#26 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#27 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 14 (Thread 0x7fffb77fe6c0 (LWP 2299592) "emacs"):
#0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1 0x00007ffff2e91e44 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=4294967295, nr=202) at ./nptl/cancellation.c:49
#2 0x00007ffff2e9245c in __futex_abstimed_wait_common64 (private=0, futex_word=0x5555571bbae0, expected=<optimized out>, op=<optimized out>, abstime=0x0, cancel=true) at ./nptl/futex-internal.c:57
#3 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
#4 0x00007ffff2e924bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#5 0x00007ffff2e949c8 in __pthread_cond_wait_common (cond=0x5555571bbac0, mutex=0x5555559c3c20 <global_lock>, clockid=0, abstime=0x0) at ./nptl/pthread_cond_wait.c:421
#6 ___pthread_cond_wait (cond=cond@entry=0x5555571bbac0, mutex=mutex@entry=0x5555559c3c20 <global_lock>) at ./nptl/pthread_cond_wait.c:453
#7 0x00005555557efc85 in sys_cond_wait (sys_cond=sys_cond@entry=0x5555571bbac0, sys_mutex=sys_mutex@entry=0x5555559c3c20 <global_lock>) at ../../src/systhread.c:172
#8 0x00005555557ee9bf in lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x55555bb885f0, new_count=0) at ../../src/thread.c:234
#9 lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x55555bb885f0, new_count=0) at ../../src/thread.c:212
#10 0x00005555557eeb36 in lisp_mutex_lock (mutex=<optimized out>, new_count=0) at ../../src/thread.c:249
#11 mutex_lock_callback (arg=<optimized out>) at ../../src/thread.c:339
#12 0x00005555557ee7e5 in flush_stack_call_func (func=0x5555557eeb20 <mutex_lock_callback>, arg=0x5555571bbaa0) at ../../src/lisp.h:4476
#13 Fmutex_lock (mutex=0x5555571bbaa5) at ../../src/thread.c:367
#14 0x00007fffe8dba0a3 in F6d696d652d7665726966792d6170706c69636174696f6e2f2a2d7369676e61747572652d696e7465726e616c_mime_verify_application_signature_internal_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/mime-pgp-321fbc8b-2f8a3100.eln
#15 0x0000555555767124 in eval_sub (form=form@entry=0x55555cf23aa3) at ../../src/eval.c:2670
#16 0x0000555555769c1f in internal_lisp_condition_case (var=<optimized out>, bodyform=0x55555cf23aa3, handlers=<optimized out>) at ../../src/eval.c:1617
#17 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#18 0x0000555555769dac in Flet (args=0x55555cf23783) at ../../src/eval.c:1164
#19 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#20 0x0000555555767e00 in Fprogn (body=<optimized out>) at ../../src/eval.c:445
#21 funcall_lambda (fun=<optimized out>, nargs=<optimized out>, arg_vector=<optimized out>) at ../../src/eval.c:3421
#22 0x0000555555768295 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffb77fd318) at ../../src/eval.c:3177
#23 0x00005555557ee6b0 in invoke_thread_function () at ../../src/thread.c:747
#24 0x00005555557633a4 in internal_condition_case (bfun=bfun@entry=0x5555557ee680 <invoke_thread_function>, handlers=handlers@entry=0x30, hfun=hfun@entry=0x5555557ee550 <record_thread_error>) at ../../src/eval.c:1690
#25 0x00005555557eef0a in run_thread (state=0x55555bb885f0) at ../../src/thread.c:818
#26 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#27 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 12 (Thread 0x7fffd13f86c0 (LWP 2299590) "emacs"):
#0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1 0x00007ffff2e91e44 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=4294967295, nr=202) at ./nptl/cancellation.c:49
#2 0x00007ffff2e9245c in __futex_abstimed_wait_common64 (private=0, futex_word=0x5555571bbae0, expected=<optimized out>, op=<optimized out>, abstime=0x0, cancel=true) at ./nptl/futex-internal.c:57
#3 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
#4 0x00007ffff2e924bb in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x5555571bbae0, expected=<optimized out>, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#5 0x00007ffff2e949c8 in __pthread_cond_wait_common (cond=0x5555571bbac0, mutex=0x5555559c3c20 <global_lock>, clockid=0, abstime=0x0) at ./nptl/pthread_cond_wait.c:421
#6 ___pthread_cond_wait (cond=cond@entry=0x5555571bbac0, mutex=mutex@entry=0x5555559c3c20 <global_lock>) at ./nptl/pthread_cond_wait.c:453
#7 0x00005555557efc85 in sys_cond_wait (sys_cond=sys_cond@entry=0x5555571bbac0, sys_mutex=sys_mutex@entry=0x5555559c3c20 <global_lock>) at ../../src/systhread.c:172
#8 0x00005555557ee9bf in lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x555558ec9b80, new_count=0) at ../../src/thread.c:234
#9 lisp_mutex_lock_for_thread (mutex=0x5555571bbab0, locker=0x555558ec9b80, new_count=0) at ../../src/thread.c:212
#10 0x00005555557eeb36 in lisp_mutex_lock (mutex=<optimized out>, new_count=0) at ../../src/thread.c:249
#11 mutex_lock_callback (arg=<optimized out>) at ../../src/thread.c:339
#12 0x00005555557ee7e5 in flush_stack_call_func (func=0x5555557eeb20 <mutex_lock_callback>, arg=0x5555571bbaa0) at ../../src/lisp.h:4476
#13 Fmutex_lock (mutex=0x5555571bbaa5) at ../../src/thread.c:367
#14 0x00007fffe8dba0a3 in F6d696d652d7665726966792d6170706c69636174696f6e2f2a2d7369676e61747572652d696e7465726e616c_mime_verify_application_signature_internal_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/mime-pgp-321fbc8b-2f8a3100.eln
#15 0x0000555555767124 in eval_sub (form=form@entry=0x55555ad60203) at ../../src/eval.c:2670
#16 0x0000555555769c1f in internal_lisp_condition_case (var=<optimized out>, bodyform=0x55555ad60203, handlers=<optimized out>) at ../../src/eval.c:1617
#17 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#18 0x0000555555769dac in Flet (args=0x55555ad60393) at ../../src/eval.c:1164
#19 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#20 0x0000555555767e00 in Fprogn (body=<optimized out>) at ../../src/eval.c:445
#21 funcall_lambda (fun=<optimized out>, nargs=<optimized out>, arg_vector=<optimized out>) at ../../src/eval.c:3421
#22 0x0000555555768295 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffd13f7318) at ../../src/eval.c:3177
#23 0x00005555557ee6b0 in invoke_thread_function () at ../../src/thread.c:747
#24 0x00005555557633a4 in internal_condition_case (bfun=bfun@entry=0x5555557ee680 <invoke_thread_function>, handlers=handlers@entry=0x30, hfun=hfun@entry=0x5555557ee550 <record_thread_error>) at ../../src/eval.c:1690
#25 0x00005555557eef0a in run_thread (state=0x555558ec9b80) at ../../src/thread.c:818
#26 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#27 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 9 (Thread 0x7fffd37fe6c0 (LWP 2299586) "emacs"):
#0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1 0x00007ffff2e91e44 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=a3@entry=2147483647, a4=a4@entry=0, a5=a5@entry=0, a6=a6@entry=0, nr=7) at ./nptl/cancellation.c:49
#2 0x00007ffff2e91e8d in __syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=a3@entry=2147483647, a4=a4@entry=0, a5=a5@entry=0, a6=a6@entry=0, nr=7) at ./nptl/cancellation.c:75
#3 0x00007ffff2f06be6 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=2147483647) at ../sysdeps/unix/sysv/linux/poll.c:29
#4 0x00007ffff74252ee in poll (__fds=<optimized out>, __nfds=<optimized out>, __timeout=2147483647) at /usr/include/x86_64-linux-gnu/bits/poll2.h:44
#5 -[GSRunLoopCtxt pollUntil:within:] (self=<optimized out>, _cmd=0x7ffff76a9880 <_OBJC_SELECTOR_TABLE+1184>, milliseconds=2147483647, contexts=0x7fffc0007360) at ./Source/unix/GSRunLoopCtxt.m:395
#6 0x00007ffff733bf36 in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x7fffc0007310, _cmd=0x7ffff76a98b0 <_OBJC_SELECTOR_TABLE+1232>, mode=0x7ffff76aa6b0 <_OBJC_INSTANCE_2>, limit_date=0x5555560462d0) at ./Source/NSRunLoop.m:1265
#7 0x00007ffff733bbc8 in -[NSRunLoop runMode:beforeDate:] (self=0x7fffc0007310, _cmd=<optimized out>, mode=0x7ffff76aa6b0 <_OBJC_INSTANCE_2>, date=<optimized out>) at ./Source/NSRunLoop.m:1345
#8 0x00007ffff7c62882 in -[GSDisplayServer(EventOps) getEventMatchingMask:beforeDate:inMode:dequeue:] (self=<optimized out>, _cmd=<optimized out>, mask=<optimized out>, limit=<optimized out>, mode=<optimized out>, flag=<optimized out>) at ./Source/GSDisplayServer.m:1037
#9 0x00007fffecb6b923 in -[XGServer(X11Ops) getEventMatchingMask:beforeDate:inMode:dequeue:] (self=0x555555fdd590, _cmd=<optimized out>, mask=4294967295, limit=0x5555560462d0, mode=0x7ffff76aa6b0 <_OBJC_INSTANCE_2>, flag=1 '\001') at ./Source/x11/XGServerEvent.m:2743
#10 0x00007ffff7a85766 in DPSPeekEvent (ctxt=<optimized out>, mask=<optimized out>, limit=<optimized out>, mode=<optimized out>) at ../Headers/Additions/GNUstepGUI/GSDisplayServer.h:210
#11 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (self=0x555555a2e920, _cmd=0x7ffff7dbf5b0 <_OBJC_SELECTOR_TABLE+2928>, mask=<optimized out>, expiration=0x5555560462d0, mode=0x7ffff76aa6b0 <_OBJC_INSTANCE_2>, flag=1 '\001') at ./Source/NSApplication.m:2208
#12 0x00007ffff7a877cc in -[NSApplication run] (self=0x555555a2e920, _cmd=<optimized out>) at ./Source/NSApplication.m:1579
#13 0x000055555582e689 in ns_select_1 (nfds=<optimized out>, readfds=readfds@entry=0x7fffd37fc970, writefds=writefds@entry=0x7fffd37fc9f0, exceptfds=exceptfds@entry=0x0, timeout=timeout@entry=0x7fffd37fc840, sigmask=sigmask@entry=0x0, run_loop_only=0 '\000') at ../../src/nsterm.m:5152
#14 0x00005555558306b5 in ns_select (nfds=<optimized out>, readfds=readfds@entry=0x7fffd37fc970, writefds=writefds@entry=0x7fffd37fc9f0, exceptfds=exceptfds@entry=0x0, timeout=timeout@entry=0x7fffd37fc840, sigmask=sigmask@entry=0x0) at ../../src/nsterm.m:5204
#15 0x00005555557c8591 in wait_reading_process_output (time_limit=<optimized out>, nsecs=<optimized out>, read_kbd=read_kbd@entry=0, do_display=do_display@entry=false, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x55555d0d84b0, just_wait_proc=0) at ../../src/process.c:5800
#16 0x00005555557cab71 in Faccept_process_output (process=<optimized out>, seconds=<optimized out>, millisec=<optimized out>, just_this_one=<optimized out>) at ../../src/process.c:4958
#17 0x00007fffe91a9c2e in F6570672d776169742d666f722d636f6d706c6574696f6e_epg_wait_for_completion_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/epg-de089247-2d45a2ae.eln
#18 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffd37fccc0) at ../../src/eval.c:3177
#19 0x00007fffe91b3c43 in F6570672d7665726966792d737472696e67_epg_verify_string_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/epg-de089247-2d45a2ae.eln
#20 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffd37fceb0) at ../../src/eval.c:3177
#21 0x00007fffe8dba109 in F6d696d652d7665726966792d6170706c69636174696f6e2f2a2d7369676e61747572652d696e7465726e616c_mime_verify_application_signature_internal_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/mime-pgp-321fbc8b-2f8a3100.eln
#22 0x0000555555767124 in eval_sub (form=form@entry=0x55555cf276b3) at ../../src/eval.c:2670
#23 0x0000555555769c1f in internal_lisp_condition_case (var=<optimized out>, bodyform=0x55555cf276b3, handlers=<optimized out>) at ../../src/eval.c:1617
#24 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#25 0x0000555555769dac in Flet (args=0x55555cf27393) at ../../src/eval.c:1164
#26 0x0000555555767015 in eval_sub (form=<optimized out>) at ../../src/eval.c:2618
#27 0x0000555555767e00 in Fprogn (body=<optimized out>) at ../../src/eval.c:445
#28 funcall_lambda (fun=<optimized out>, nargs=<optimized out>, arg_vector=<optimized out>) at ../../src/eval.c:3421
#29 0x0000555555768295 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffd37fd318) at ../../src/eval.c:3177
#30 0x00005555557ee6b0 in invoke_thread_function () at ../../src/thread.c:747
#31 0x00005555557633a4 in internal_condition_case (bfun=bfun@entry=0x5555557ee680 <invoke_thread_function>, handlers=handlers@entry=0x30, hfun=hfun@entry=0x5555557ee550 <record_thread_error>) at ../../src/eval.c:1690
#32 0x00005555557eef0a in run_thread (state=0x5555571f4c70) at ../../src/thread.c:818
#33 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#34 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 5 (Thread 0x7fffe15fd6c0 (LWP 2299567) "gdbus"):
#0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1 0x00007ffff2e91e44 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=8, a6=a6@entry=0, nr=271) at ./nptl/cancellation.c:49
#2 0x00007ffff2e91e8d in __syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=8, a6=a6@entry=0, nr=271) at ./nptl/cancellation.c:75
#3 0x00007ffff2f0710e in __GI_ppoll (fds=fds@entry=0x7fffd4000c20, nfds=nfds@entry=2, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42
#4 0x00007ffff630aaf4 in ppoll (__fds=0x7fffd4000c20, __nfds=2, __timeout=0x0, __ss=0x0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:101
#5 g_main_context_poll_unlocked (priority=<optimized out>, context=0x555558790a10, timeout_usec=<optimized out>, fds=0x7fffd4000c20, n_fds=2) at ../../../glib/gmain.c:4811
#6 g_main_context_iterate_unlocked (context=0x555558790a10, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4485
#7 0x00007ffff630b4cf in g_main_loop_run (loop=0x5555587faa70) at ../../../glib/gmain.c:4695
#8 0x00007ffff65347aa in gdbus_shared_thread_func (user_data=0x5555587fbf40) at ../../../gio/gdbusprivate.c:284
#9 0x00007ffff633d0e6 in g_thread_proxy (data=0x5555587faa90) at ../../../glib/gthread.c:893
#10 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#11 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 4 (Thread 0x7fffe1dfe6c0 (LWP 2299566) "gmain"):
#0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1 0x00007ffff2e91e44 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=8, a6=a6@entry=0, nr=271) at ./nptl/cancellation.c:49
#2 0x00007ffff2e91e8d in __syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=8, a6=a6@entry=0, nr=271) at ./nptl/cancellation.c:75
#3 0x00007ffff2f0710e in __GI_ppoll (fds=fds@entry=0x7fffdc000be0, nfds=nfds@entry=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42
#4 0x00007ffff630aaf4 in ppoll (__fds=0x7fffdc000be0, __nfds=1, __timeout=0x0, __ss=0x0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:101
#5 g_main_context_poll_unlocked (priority=<optimized out>, context=0x555558c6bb80, timeout_usec=<optimized out>, fds=0x7fffdc000be0, n_fds=1) at ../../../glib/gmain.c:4811
#6 g_main_context_iterate_unlocked (context=context@entry=0x555558c6bb80, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4485
#7 0x00007ffff630b1d0 in g_main_context_iteration (context=0x555558c6bb80, may_block=may_block@entry=1) at ../../../glib/gmain.c:4556
#8 0x00007ffff630b221 in glib_worker_main (data=<optimized out>) at ../../../glib/gmain.c:6764
#9 0x00007ffff633d0e6 in g_thread_proxy (data=0x55555cbe80d0) at ../../../glib/gthread.c:893
#10 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#11 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 3 (Thread 0x7fffe25ff6c0 (LWP 2299565) "pool-spawner"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007ffff633c962 in g_cond_wait_impl (cond=0x55555cbe7db8, mutex=0x55555cbe7db0) at ../../../glib/gthread-posix.c:1026
#2 g_cond_wait (cond=cond@entry=0x55555cbe7db8, mutex=mutex@entry=0x55555cbe7db0) at ../../../glib/gthread.c:1686
#3 0x00007ffff62d0b04 in g_async_queue_pop_intern_unlocked (queue=0x55555cbe7db0, wait=1, end_time=-1) at ../../../glib/gasyncqueue.c:376
#4 0x00007ffff633d3a4 in g_thread_pool_spawn_thread (data=<optimized out>) at ../../../glib/gthreadpool.c:297
#5 0x00007ffff633d0e6 in g_thread_proxy (data=0x55555cbe7e20) at ../../../glib/gthread.c:893
#6 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#7 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 2 (Thread 0x7fffe9a446c0 (LWP 2299558) "emacs"):
#0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1 0x00007ffff2e91e44 in __internal_syscall_cancel (a1=<optimized out>, a2=a2@entry=93825008103424, a3=a3@entry=0, a4=a4@entry=0, a5=<optimized out>, a6=a6@entry=140737113239888, nr=270) at ./nptl/cancellation.c:49
#2 0x00007ffff2e91e8d in __syscall_cancel (a1=<optimized out>, a2=a2@entry=93825008103424, a3=a3@entry=0, a4=a4@entry=0, a5=<optimized out>, a6=a6@entry=140737113239888, nr=270) at ./nptl/cancellation.c:75
#3 0x00007ffff2f10acc in pselect64_syscall (nfds=<optimized out>, readfds=0x555556477000, writefds=0x0, exceptfds=0x0, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:34
#4 __pselect (nfds=<optimized out>, readfds=readfds@entry=0x7fffe9a432c0, writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:56
#5 0x000055555581eb3f in -[EmacsApp fd:handler:] (self=<optimized out>, _cmd=<optimized out>, unused=<optimized out>) at ../../src/nsterm.m:6639
#6 0x00007ffff7373c76 in nsthreadLauncher (thread=0x55555656cc60) at ./Source/NSThread.m:1490
#7 0x00007ffff2e95428 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#8 0x00007ffff2f13b78 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 1 (Thread 0x7fffeebe4240 (LWP 2299551) "emacs"):
#0 futex_wait (futex_word=0x5555559c3c20 <global_lock>, expected=2, private=0) at ../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait (futex=futex@entry=0x5555559c3c20 <global_lock>, private=0) at ./nptl/lowlevellock.c:49
#2 0x00007ffff2e98921 in lll_mutex_lock_optimized (mutex=0x5555559c3c20 <global_lock>) at ./nptl/pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=mutex@entry=0x5555559c3c20 <global_lock>) at ./nptl/pthread_mutex_lock.c:93
#4 0x00005555557efc25 in sys_mutex_lock (sys_mutex=sys_mutex@entry=0x5555559c3c20 <global_lock>) at ../../src/systhread.c:142
#5 0x00005555557eedec in acquire_global_lock (self=0x5555558dad20 <main_thread>) at ../../src/thread.c:160
#6 really_call_select (arg=0x7fffffffb6c0) at ../../src/thread.c:636
#7 0x00005555557ef610 in flush_stack_call_func (func=0x5555557eed60 <really_call_select>, arg=0x7fffffffb6c0) at ../../src/lisp.h:4476
#8 thread_select (func=<optimized out>, max_fds=max_fds@entry=27, rfds=rfds@entry=0x7fffffffbac0, wfds=wfds@entry=0x7fffffffbb40, efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffb990, sigmask=0x0) at ../../src/thread.c:659
#9 0x000055555582e4f4 in ns_select_1 (nfds=27, readfds=readfds@entry=0x7fffffffbac0, writefds=writefds@entry=0x7fffffffbb40, exceptfds=exceptfds@entry=0x0, timeout=timeout@entry=0x7fffffffb990, sigmask=sigmask@entry=0x0, run_loop_only=0 '\000') at ../../src/nsterm.m:5076
#10 0x00005555558306b5 in ns_select (nfds=<optimized out>, readfds=readfds@entry=0x7fffffffbac0, writefds=writefds@entry=0x7fffffffbb40, exceptfds=exceptfds@entry=0x0, timeout=timeout@entry=0x7fffffffb990, sigmask=sigmask@entry=0x0) at ../../src/nsterm.m:5204
#11 0x00005555557c8591 in wait_reading_process_output (time_limit=<optimized out>, nsecs=<optimized out>, read_kbd=read_kbd@entry=0, do_display=do_display@entry=false, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x55555698a7b0, just_wait_proc=0) at ../../src/process.c:5800
#12 0x00005555557cab71 in Faccept_process_output (process=<optimized out>, seconds=<optimized out>, millisec=<optimized out>, just_this_one=<optimized out>) at ../../src/process.c:4958
#13 0x00007fffe39ce3d8 in F656c6d6f2d6e6e74702d726561642d636f6e74656e7473_elmo_nntp_read_contents_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-nntp-ff7a2d85-e030b559.eln
#14 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/lisp.h:2226
#15 0x0000555555768295 in Ffuncall (nargs=nargs@entry=3, args=0x7fffffffbf10) at ../../src/eval.c:3177
#16 0x0000555555768600 in Fapply (nargs=2, args=0x7fffffffbfb0) at ../../src/eval.c:2834
#17 0x00007fffe3a51196 in F656c6d6f2d6e65742d666f6c6465722d6c6973742d6d657373616765732d696e7465726e616c_elmo_net_folder_list_messages_internal_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-net-3892bc71-7bdcbd17.eln
#18 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/lisp.h:2226
#19 0x0000555555768295 in Ffuncall (nargs=nargs@entry=3, args=0x7fffffffc160) at ../../src/eval.c:3177
#20 0x0000555555768600 in Fapply (nargs=2, args=0x7fffffffc1f0) at ../../src/eval.c:2834
#21 0x00007fffe8da0796 in F6c756e612d63616c6c2d6e6578742d6d6574686f64_luna_call_next_method_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#22 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc288) at ../../src/eval.c:3177
#23 0x00007fffe8da0a0c in F6c756e612d6170706c792d67656e65726963_luna_apply_generic_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#24 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc320) at ../../src/eval.c:3177
#25 0x00007fffe90eb336 in F656c6d6f2d666f6c6465722d6c6973742d6d657373616765732d696e7465726e616c_elmo_folder_list_messages_internal_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-c2ff9e10-39c3310f.eln
#26 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/lisp.h:2226
#27 0x0000555555768295 in Ffuncall (nargs=nargs@entry=4, args=0x7fffffffc4a0) at ../../src/eval.c:3177
#28 0x0000555555768600 in Fapply (nargs=2, args=0x7fffffffc540) at ../../src/eval.c:2834
#29 0x00007fffe8da0796 in F6c756e612d63616c6c2d6e6578742d6d6574686f64_luna_call_next_method_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#30 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc5d8) at ../../src/eval.c:3177
#31 0x00007fffe8da0a0c in F6c756e612d6170706c792d67656e65726963_luna_apply_generic_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#32 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc670) at ../../src/eval.c:3177
#33 0x00007fffe90eb11e in F656c6d6f2d666f6c6465722d6c6973742d6d65737361676573_elmo_folder_list_messages_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-c2ff9e10-39c3310f.eln
#34 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/lisp.h:2226
#35 0x0000555555768295 in Ffuncall (nargs=nargs@entry=6, args=0x7fffffffc7f0) at ../../src/eval.c:3177
#36 0x0000555555768600 in Fapply (nargs=2, args=0x7fffffffc8a0) at ../../src/eval.c:2834
#37 0x00007fffe8da0796 in F6c756e612d63616c6c2d6e6578742d6d6574686f64_luna_call_next_method_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#38 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc938) at ../../src/eval.c:3177
#39 0x00007fffe8da0a0c in F6c756e612d6170706c792d67656e65726963_luna_apply_generic_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#40 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc9d0) at ../../src/eval.c:3177
#41 0x00007fffe90f521b in F656c6d6f2d666f6c6465722d73796e6368726f6e697a65_elmo_folder_synchronize_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-c2ff9e10-39c3310f.eln
#42 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffcd20) at ../../src/eval.c:3177
#43 0x00007fffe3bae4ac in F776c2d73756d6d6172792d73796e632d757064617465_wl_summary_sync_update_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/wl-summary-5e25b72b-4ed37435.eln
#44 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffce30) at ../../src/eval.c:3177
#45 0x00007fffe3ba701a in F776c2d73756d6d6172792d73796e632d666f7263652d757064617465_wl_summary_sync_force_update_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/wl-summary-5e25b72b-4ed37435.eln
#46 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/lisp.h:2226
#47 0x0000555555768295 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffffcfb8) at ../../src/eval.c:3177
#48 0x00005555557b50c8 in bcall0 (f=<optimized out>) at ../../src/comp.c:853
#49 0x00005555557646ef in do_one_unbind (unwinding=true, bindflag=SET_INTERNAL_UNBIND, this_binding=0x7fffffffcfe0) at ../../src/eval.c:3782
#50 unbind_to (count=..., value=0x0) at ../../src/eval.c:3923
#51 0x00007fffe3bb2ca9 in F776c2d73756d6d6172792d676f746f2d666f6c6465722d73756272_wl_summary_goto_folder_subr_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/wl-summary-5e25b72b-4ed37435.eln
#52 0x000055555576636c in funcall_subr (subr=<optimized out>, numargs=<optimized out>, args=<optimized out>) at ../../src/eval.c:3257
#53 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd630) at ../../src/eval.c:3177
#54 0x00007fffe39f56fb in F776c2d666f6c6465722d6a756d702d746f2d63757272656e742d656e74697479_wl_folder_jump_to_current_entity_0 () at /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/wl-folder-e094e30b-26c1d9a0.eln
#55 0x0000555555768295 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd738) at ../../src/eval.c:3177
#56 0x00005555557604e4 in Ffuncall_interactively (nargs=2, args=0x7fffffffd738) at ../../src/callint.c:252
#57 0x0000555555768295 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7fffffffd730) at ../../src/eval.c:3177
#58 0x0000555555761cbe in Fcall_interactively (function=<optimized out>, record_flag=<optimized out>, keys=<optimized out>) at ../../src/callint.c:802
#59 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/lisp.h:2226
#60 0x0000555555768295 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffda90) at ../../src/eval.c:3177
#61 0x00005555556e763f in command_loop_1 () at ../../src/keyboard.c:1545
#62 0x00005555557633a4 in internal_condition_case (bfun=bfun@entry=0x5555556e7250 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x5555556d9f50 <cmd_error>) at ../../src/eval.c:1690
#63 0x00005555556d1f26 in command_loop_2 (handlers=0x90) at ../../src/keyboard.c:1163
#64 0x00005555557632fe in internal_catch (tag=tag@entry=0x11f10, func=func@entry=0x5555556d1f00 <command_loop_2>, arg=arg@entry=0x90) at ../../src/eval.c:1370
#65 0x00005555556d1ec3 in command_loop () at ../../src/keyboard.c:1141
#66 0x00005555556d9b11 in recursive_edit_1 () at ../../src/keyboard.c:749
#67 0x00005555556d9e83 in Frecursive_edit () at ../../src/keyboard.c:832
#68 0x00005555555ef6c3 in main (argc=<optimized out>, argv=0x7fffffffdf08) at ../../src/emacs.c:2629
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.
Received: (at 80110) by debbugs.gnu.org; 2 Jan 2026 07:54:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 02:54:14 2026
Received: from localhost ([127.0.0.1]:55904 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vbZzC-0003yb-38
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 02:54:14 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:37612)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vbZz8-0003yL-JG
for 80110 <at> debbugs.gnu.org; Fri, 02 Jan 2026 02:54:11 -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 1vbZz2-0000qr-GP; Fri, 02 Jan 2026 02:54:04 -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=Nx0jjErFNK/GUSPL+CkiA+EozNRYb3ynlj7nEhjjOzQ=; b=qh/EKr222aD6u/iW3nKy
5U5ylxSod90P4db7WVJdomKwp1YWXMdxHXlIxqv7eRTlGi9Fy/fxZgfW8VDIOK/3m4TmJjnU/Vc+m
f4ktMvdenyIS97jcudJxs1rZE8UF3KqrQjjaHdJrTgzxrbAm4V+BegKJMfsYu+TjkyHKyCrZvyJBY
XHXhCnp4YTkanNes2QkNkHZZbrxBnaA3ggN479TApeSuv7vfC5USDuDomyD7ww6yT1gYdlei3xkuj
Wk/AlSZoWT/2K3KW4tE1eQ+nQDBzVPgfIGTsx2C3I8+PeHXHXz4/CxpAQdqvAwmZv8aTPJr69SrN6
4vcnUwXDhLE1uQ==;
Date: Fri, 02 Jan 2026 09:54:01 +0200
Message-Id: <86jyy0o3fq.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Yavor Doganov <yavor@HIDDEN>
In-Reply-To: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor
Doganov on Fri, 02 Jan 2026 08:58:24 +0200)
Subject: Re: bug#80110: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep
References: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 80110
Cc: gerd.moellmann@HIDDEN, 80110 <at> debbugs.gnu.org,
Alan Third <alan@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: yavor@HIDDEN, gerd.moellmann@HIDDEN
> Date: Fri, 02 Jan 2026 08:58:24 +0200
> From: Yavor Doganov <yavor@HIDDEN>
>
> This is a reincarnation of Bug#69561 but it happens on GNU/Linux.
> It is fairly easy to reproduce with my MUA Wanderlust -- I am not able
> to read more than a few mails or Usenet articles. It happened also
> with ERC and TRAMP and I bet it can be reproduced with Gnus as well.
>
> Partially reverting Gerd Möllmann's commit 4ac4cec fixes the problem
> immediately. I admit I don't understand the code well and cannot
> figure out why execution should proceed further instead of simply
> returning thread_select as before that change. The freezes always
> happen on the main thread, when the second condition is true:
>
> (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0)
>
> And if this is not the main thread, it seems wrong to call [NSApp run].
>
> The freezes do not occur if I start Emacs with -nw so it has to be
> something related to the event loop. I am not sure the attached patch
> is correct but I wasn't able to trigger a freeze for more than a month
> (and I use Emacs 12-14 hours per day for many tasks).
The amount of NS expertise in our team is very limited, to put it
mildly, so please always explain in detail the meaning and intended
effects of the various NS-related conditions, otherwise it is very
hard for us to review your patches and provide meaningful feedback.
(I don't doubt your expertise in GNUstep, but we must try to
understand the implications of the proposed changes on the ways the
relevant Emacs parts fundamentally work, which is our expertise here,
and we need the details I'm asking to provide to make the connection,
without which it is impossible to provide meaningful feedback to your
changes, let alone approve them for installing.) In this particular
case:
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -5073,6 +5073,9 @@ Function modeled after x_draw_glyph_string_box ().
>
> if (![NSThread isMainThread]
> || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
> +#ifdef NS_IMPL_GNUSTEP
> + return
> +#endif
> thread_select (pselect, nfds, readfds, writefds,
> exceptfds, timeout, sigmask);
what does NS_IMPL_GNUSTEP mean, when it is true and when false? IOW,
which configurations and builds of Emacs is it supposed to affect?
> @@ -5213,7 +5216,7 @@ Function modeled after x_draw_glyph_string_box ().
> NSTRACE_WHEN (NSTRACE_GROUP_EVENTS, "ns_run_loop_break");
>
> /* If we don't have a GUI, don't send the event. */
> - if (NSApp != NULL)
> + if (NSApp != nil)
> ns_send_appdefined(-1);
Is this a typo fix? If not, please tell the difference between NULL
and nil in thyis context, and its significance.
As for this backtrace:
> (gdb) bt
> #0 futex_wait (futex_word=0x5555559c3c20 <global_lock>, expected=2, private=0)
> at ../sysdeps/nptl/futex-internal.h:146
> #1 __GI___lll_lock_wait (futex=futex@entry=0x5555559c3c20 <global_lock>,
> private=0) at ./nptl/lowlevellock.c:49
> #2 0x00007ffff2e98921 in lll_mutex_lock_optimized (
> mutex=0x5555559c3c20 <global_lock>) at ./nptl/pthread_mutex_lock.c:48
> #3 ___pthread_mutex_lock (mutex=mutex@entry=0x5555559c3c20 <global_lock>)
> at ./nptl/pthread_mutex_lock.c:93
> #4 0x00005555557efc25 in sys_mutex_lock (
> sys_mutex=sys_mutex@entry=0x5555559c3c20 <global_lock>)
> at ../../src/systhread.c:142
> #5 0x00005555557eedec in acquire_global_lock (
> self=0x5555558dad20 <main_thread>) at ../../src/thread.c:160
> #6 really_call_select (arg=0x7fffffffb6c0) at ../../src/thread.c:636
> #7 0x00005555557ef610 in flush_stack_call_func (
> func=0x5555557eed60 <really_call_select>, arg=0x7fffffffb6c0)
> at ../../src/lisp.h:4476
> #8 thread_select (func=<optimized out>, max_fds=max_fds@entry=27,
> rfds=rfds@entry=0x7fffffffbac0, wfds=wfds@entry=0x7fffffffbb40,
> efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffb990, sigmask=0x0)
> at ../../src/thread.c:659
> #9 0x000055555582e4f4 in ns_select_1 (nfds=27,
> readfds=readfds@entry=0x7fffffffbac0,
> writefds=writefds@entry=0x7fffffffbb40, exceptfds=exceptfds@entry=0x0,
> timeout=timeout@entry=0x7fffffffb990, sigmask=sigmask@entry=0x0,
> run_loop_only=0 '\000') at ../../src/nsterm.m:5076
please tell when it was taken. Was this taken when Emacs froze? if
so, I'm not sure how reverting Gerd's changes would have solved this,
since AFAICT the freeze is inside this call of thread_select:
if (![NSThread isMainThread]
|| (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
thread_select (pselect, nfds, readfds, writefds, <<<<<<<<<<<<<<<<<<<<
exceptfds, timeout, sigmask);
else
and Gerd's change just prevented the code from returning right after
thread_select returns. But if thread_select doesn't return, how would
reverting that help? Or what am I missing?
Thanks.
P.S. I added Alan to the discussion, since he was part of discussion
of bug#69561.
bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 2 Jan 2026 06:58:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 01:58:52 2026
Received: from localhost ([127.0.0.1]:55768 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vbZ7b-0001Ms-Tb
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 01:58:52 -0500
Received: from lists.gnu.org ([2001:470:142::17]:59504)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vbZ7Z-0001MZ-TL
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 01:58:50 -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 <yavor@HIDDEN>) id 1vbZ7P-00057W-3x
for bug-gnu-emacs@HIDDEN; Fri, 02 Jan 2026 01:58:40 -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 <yavor@HIDDEN>) id 1vbZ7O-0003af-Rv
for bug-gnu-emacs@HIDDEN; Fri, 02 Jan 2026 01:58:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Subject:To:From:Date:in-reply-to:
references; bh=q7pZHrLRFaPGyXQRe4puqnDQ14yatKTuurga2fgUVjI=; b=UBBf6PLmVsTaHk
h245cVNV7HQg2LQV51eA+s7pSKDUJBHfHDhMi30bnLOEslLjPQCcWRGlg+JZ/zFD83pOixZVQTEIW
2Iok5SUR0nBM7lejFxnmTgqdLHoDM7zeeXm5ZqAG7emGuce9YMajV+WGOc4MIFKcM6ZFltB1hCr4G
mUiBUWEF9t2hUEjMEqFPVmwNDGJIvALCG0P52RZ/NWOsZgpmN2dm9LVodRqEkWnNeFaetWfRWjmSb
u4I4nMkBzqhrQmYwN9F/dhOjqBVzbvwSK3gFYEA0NFU692brb4oOD4Z93TVCDkQyEXTPmkA4f8uKE
Rta8crou6UzS8t7wcRgA==;
Date: Fri, 02 Jan 2026 08:58:24 +0200
Message-ID: <874ip4qz5b.GNU's_not_UNIX!-yavor@HIDDEN>
From: Yavor Doganov <yavor@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 30.2; [PATCH] NS: Frequent UI freezes on GNUstep
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2
(x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
X-Debbugs-Cc: yavor@HIDDEN, gerd.moellmann@HIDDEN
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: multipart/mixed; boundary="Multipart_Fri_Jan__2_08:58:24_2026-1"
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--Multipart_Fri_Jan__2_08:58:24_2026-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is a reincarnation of Bug#69561 but it happens on GNU/Linux.
It is fairly easy to reproduce with my MUA Wanderlust -- I am not able
to read more than a few mails or Usenet articles. It happened also
with ERC and TRAMP and I bet it can be reproduced with Gnus as well.
Partially reverting Gerd Möllmann's commit 4ac4cec fixes the problem
immediately. I admit I don't understand the code well and cannot
figure out why execution should proceed further instead of simply
returning thread_select as before that change. The freezes always
happen on the main thread, when the second condition is true:
(timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0)
And if this is not the main thread, it seems wrong to call [NSApp run].
The freezes do not occur if I start Emacs with -nw so it has to be
something related to the event loop. I am not sure the attached patch
is correct but I wasn't able to trigger a freeze for more than a month
(and I use Emacs 12-14 hours per day for many tasks).
In GNU Emacs 31.0.50 (build 11, x86_64-pc-linux-gnu, NS
gnustep-gui-0.32.0) of 2026-01-02 built on patilan
Repository revision: 0db173fa2336d72739216aa2e92ef61545f24d1c
Repository branch: master
Windowing system distributor 'GNU', version 10.3.32
System Description: Debian GNU/Linux forky/sid
Configured using:
'configure --with-ns
--enable-locallisppath=/etc/emacs:/usr/share/emacs/30.2/site-lisp:/usr/share/emacs/site-lisp'
(gdb) bt
#0 futex_wait (futex_word=0x5555559c3c20 <global_lock>, expected=2, private=0)
at ../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait (futex=futex@entry=0x5555559c3c20 <global_lock>,
private=0) at ./nptl/lowlevellock.c:49
#2 0x00007ffff2e98921 in lll_mutex_lock_optimized (
mutex=0x5555559c3c20 <global_lock>) at ./nptl/pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=mutex@entry=0x5555559c3c20 <global_lock>)
at ./nptl/pthread_mutex_lock.c:93
#4 0x00005555557efc25 in sys_mutex_lock (
sys_mutex=sys_mutex@entry=0x5555559c3c20 <global_lock>)
at ../../src/systhread.c:142
#5 0x00005555557eedec in acquire_global_lock (
self=0x5555558dad20 <main_thread>) at ../../src/thread.c:160
#6 really_call_select (arg=0x7fffffffb6c0) at ../../src/thread.c:636
#7 0x00005555557ef610 in flush_stack_call_func (
func=0x5555557eed60 <really_call_select>, arg=0x7fffffffb6c0)
at ../../src/lisp.h:4476
#8 thread_select (func=<optimized out>, max_fds=max_fds@entry=27,
rfds=rfds@entry=0x7fffffffbac0, wfds=wfds@entry=0x7fffffffbb40,
efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffb990, sigmask=0x0)
at ../../src/thread.c:659
#9 0x000055555582e4f4 in ns_select_1 (nfds=27,
readfds=readfds@entry=0x7fffffffbac0,
writefds=writefds@entry=0x7fffffffbb40, exceptfds=exceptfds@entry=0x0,
timeout=timeout@entry=0x7fffffffb990, sigmask=sigmask@entry=0x0,
run_loop_only=0 '\000') at ../../src/nsterm.m:5076
#10 0x00005555558306b5 in ns_select (nfds=<optimized out>,
readfds=readfds@entry=0x7fffffffbac0,
writefds=writefds@entry=0x7fffffffbb40, exceptfds=exceptfds@entry=0x0,
timeout=timeout@entry=0x7fffffffb990, sigmask=sigmask@entry=0x0)
at ../../src/nsterm.m:5204
#11 0x00005555557c8591 in wait_reading_process_output (
time_limit=<optimized out>, nsecs=<optimized out>,
read_kbd=read_kbd@entry=0, do_display=do_display@entry=false,
wait_for_cell=wait_for_cell@entry=0x0,
wait_proc=wait_proc@entry=0x555560f652c0, just_wait_proc=0)
at ../../src/process.c:5800
#12 0x00005555557cab71 in Faccept_process_output (process=<optimized out>,
seconds=<optimized out>, millisec=<optimized out>,
just_this_one=<optimized out>) at ../../src/process.c:4958
#13 0x00007fffdf5023d8 in F656c6d6f2d6e6e74702d726561642d636f6e74656e7473_elmo_nntp_read_contents_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-nntp-ff7a2d85-e030b559.eln
#14 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at ../../src/lisp.h:2226
#15 0x0000555555768295 in Ffuncall (nargs=nargs@entry=3, args=0x7fffffffbf10)
at ../../src/eval.c:3177
#16 0x0000555555768600 in Fapply (nargs=2, args=0x7fffffffbfb0)
at ../../src/eval.c:2834
#17 0x00007fffdf585196 in F656c6d6f2d6e65742d666f6c6465722d6c6973742d6d657373616765732d696e7465726e616c_elmo_net_folder_list_messages_internal_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-net-3892bc71-7bdcbd17.eln
#18 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at ../../src/lisp.h:2226
#19 0x0000555555768295 in Ffuncall (nargs=nargs@entry=3, args=0x7fffffffc160)
at ../../src/eval.c:3177
#20 0x0000555555768600 in Fapply (nargs=2, args=0x7fffffffc1f0)
at ../../src/eval.c:2834
#21 0x00007fffe816d796 in F6c756e612d63616c6c2d6e6578742d6d6574686f64_luna_call_next_method_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#22 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc288)
at ../../src/eval.c:3177
#23 0x00007fffe816da0c in F6c756e612d6170706c792d67656e65726963_luna_apply_generic_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#24 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc320)
at ../../src/eval.c:3177
#25 0x00007fffe8180336 in F656c6d6f2d666f6c6465722d6c6973742d6d657373616765732d696e7465726e616c_elmo_folder_list_messages_internal_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-c2ff9e10-39c3310f.eln
#26 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at ../../src/lisp.h:2226
#27 0x0000555555768295 in Ffuncall (nargs=nargs@entry=4, args=0x7fffffffc4a0)
at ../../src/eval.c:3177
#28 0x0000555555768600 in Fapply (nargs=2, args=0x7fffffffc540)
at ../../src/eval.c:2834
#29 0x00007fffe816d796 in F6c756e612d63616c6c2d6e6578742d6d6574686f64_luna_call_next_method_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#30 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc5d8)
at ../../src/eval.c:3177
#31 0x00007fffe816da0c in F6c756e612d6170706c792d67656e65726963_luna_apply_generic_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#32 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc670)
at ../../src/eval.c:3177
#33 0x00007fffe818011e in F656c6d6f2d666f6c6465722d6c6973742d6d65737361676573_elmo_folder_list_messages_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-c2ff9e10-39c3310f.eln
#34 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at ../../src/lisp.h:2226
#35 0x0000555555768295 in Ffuncall (nargs=nargs@entry=6, args=0x7fffffffc7f0)
at ../../src/eval.c:3177
#36 0x0000555555768600 in Fapply (nargs=2, args=0x7fffffffc8a0)
at ../../src/eval.c:2834
#37 0x00007fffe816d796 in F6c756e612d63616c6c2d6e6578742d6d6574686f64_luna_call_next_method_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#38 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc938)
at ../../src/eval.c:3177
#39 0x00007fffe816da0c in F6c756e612d6170706c792d67656e65726963_luna_apply_generic_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/luna-ba9c01b9-aa8f5538.eln
#40 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffc9d0)
at ../../src/eval.c:3177
#41 0x00007fffe818a21b in F656c6d6f2d666f6c6465722d73796e6368726f6e697a65_elmo_folder_synchronize_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/elmo-c2ff9e10-39c3310f.eln
#42 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffcd20)
at ../../src/eval.c:3177
#43 0x00007fffe3eca4ac in F776c2d73756d6d6172792d73796e632d757064617465_wl_summary_sync_update_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/wl-summary-5e25b72b-4ed37435.eln
#44 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffce30)
at ../../src/eval.c:3177
#45 0x00007fffe3ec301a in F776c2d73756d6d6172792d73796e632d666f7263652d757064617465_wl_summary_sync_force_update_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/wl-summary-5e25b72b-4ed37435.eln
#46 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at ../../src/lisp.h:2226
#47 0x0000555555768295 in Ffuncall (nargs=nargs@entry=1,
args=args@entry=0x7fffffffcfb8) at ../../src/eval.c:3177
#48 0x00005555557b50c8 in bcall0 (f=<optimized out>) at ../../src/comp.c:853
#49 0x00005555557646ef in do_one_unbind (unwinding=true,
bindflag=SET_INTERNAL_UNBIND, this_binding=0x7fffffffcfe0)
at ../../src/eval.c:3782
#50 unbind_to (count=..., value=0x0) at ../../src/eval.c:3923
#51 0x00007fffe3ececa9 in F776c2d73756d6d6172792d676f746f2d666f6c6465722d73756272_wl_summary_goto_folder_subr_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/wl-summary-5e25b72b-4ed37435.eln
#52 0x000055555576636c in funcall_subr (subr=<optimized out>,
numargs=<optimized out>, args=<optimized out>) at ../../src/eval.c:3257
#53 0x0000555555768295 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd630)
at ../../src/eval.c:3177
#54 0x00007fffdf5296fb in F776c2d666f6c6465722d6a756d702d746f2d63757272656e742d656e74697479_wl_folder_jump_to_current_entity_0 ()
from /home/yavor/.emacs.d/eln-cache/31_0_50-e3c51b5b/wl-folder-e094e30b-26c1d9a0.eln
#55 0x0000555555768295 in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7fffffffd738) at ../../src/eval.c:3177
#56 0x00005555557604e4 in Ffuncall_interactively (nargs=2, args=0x7fffffffd738)
at ../../src/callint.c:252
#57 0x0000555555768295 in Ffuncall (nargs=nargs@entry=3,
args=args@entry=0x7fffffffd730) at ../../src/eval.c:3177
#58 0x0000555555761cbe in Fcall_interactively (function=<optimized out>,
record_flag=<optimized out>, keys=<optimized out>)
at ../../src/callint.c:802
#59 0x00005555557b27b0 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at ../../src/lisp.h:2226
#60 0x0000555555768295 in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7fffffffda90) at ../../src/eval.c:3177
#61 0x00005555556e763f in command_loop_1 () at ../../src/keyboard.c:1545
#62 0x00005555557633a4 in internal_condition_case (
bfun=bfun@entry=0x5555556e7250 <command_loop_1>,
handlers=handlers@entry=0x90, hfun=hfun@entry=0x5555556d9f50 <cmd_error>)
at ../../src/eval.c:1690
#63 0x00005555556d1f26 in command_loop_2 (handlers=0x90)
at ../../src/keyboard.c:1163
#64 0x00005555557632fe in internal_catch (tag=tag@entry=0x11f10,
func=func@entry=0x5555556d1f00 <command_loop_2>, arg=arg@entry=0x90)
at ../../src/eval.c:1370
#65 0x00005555556d1ec3 in command_loop () at ../../src/keyboard.c:1141
#66 0x00005555556d9b11 in recursive_edit_1 () at ../../src/keyboard.c:749
#67 0x00005555556d9e83 in Frecursive_edit () at ../../src/keyboard.c:832
#68 0x00005555555ef6c3 in main (argc=<optimized out>, argv=0x7fffffffdf08)
at ../../src/emacs.c:2629
Lisp Backtrace:
"epg-wait-for-completion" (0xdd252cc8)
"epg-verify-string" (0xdd252eb8)
"mime-verify-application/*-signature-internal" (0xdd252f50)
"condition-case" (0xdd253098)
"let" (0xdd2531d8)
0x5fbc24c0 Lisp type 3
--Multipart_Fri_Jan__2_08:58:24_2026-1
Content-Type: text/plain; type=patch; charset=US-ASCII
Content-Disposition: attachment; filename="0001-NS-Fix-freezes-on-GNUstep.patch"
Content-Transfer-Encoding: 8bit
From 3488a896c475dcdcc29a02107b65ff4c78724db8 Mon Sep 17 00:00:00 2001
From: Yavor Doganov <yavor@HIDDEN>
Date: Fri, 2 Jan 2026 08:46:12 +0200
Subject: [PATCH] NS: Fix freezes on GNUstep
* src/nsterm.m (ns_select_1): On GNUstep, return thread_select if
not on the main thread or timeout has expired.
(ns_run_loop_break): Use nil instead of NULL for comparison.
---
src/nsterm.m | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/nsterm.m b/src/nsterm.m
index fe5bc35086d..e0b6020f3db 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -5073,6 +5073,9 @@ Function modeled after x_draw_glyph_string_box ().
if (![NSThread isMainThread]
|| (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
+#ifdef NS_IMPL_GNUSTEP
+ return
+#endif
thread_select (pselect, nfds, readfds, writefds,
exceptfds, timeout, sigmask);
else
@@ -5213,7 +5216,7 @@ Function modeled after x_draw_glyph_string_box ().
NSTRACE_WHEN (NSTRACE_GROUP_EVENTS, "ns_run_loop_break");
/* If we don't have a GUI, don't send the event. */
- if (NSApp != NULL)
+ if (NSApp != nil)
ns_send_appdefined(-1);
}
#endif
--
2.51.0
--Multipart_Fri_Jan__2_08:58:24_2026-1--
Yavor Doganov <yavor@HIDDEN>:yavor@HIDDEN, gerd.moellmann@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.yavor@HIDDEN, gerd.moellmann@HIDDEN, bug-gnu-emacs@HIDDEN:bug#80110; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.