From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Tue, 24 Dec 2024 22:34:12 +0000 Message-ID: <87msgkaeyy.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87h66vwn1m.fsf@telefonica.net> <87y107e02u.fsf@protonmail.com> <87a5cnw6w4.fsf@telefonica.net> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31696"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, =?utf-8?Q?Gerd_M=C3=B6llmann?= , Helmut Eller , Andrea Corallo To: =?utf-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 04:21:43 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tQHxu-00085S-G7 for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 04:21:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQHx2-0008TW-2z; Tue, 24 Dec 2024 22:20:48 -0500 Original-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 ) id 1tQDTz-0006qu-Hb for emacs-devel@gnu.org; Tue, 24 Dec 2024 17:34:31 -0500 Original-Received: from mail-10630.protonmail.ch ([79.135.106.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQDTw-0001eX-Vm for emacs-devel@gnu.org; Tue, 24 Dec 2024 17:34:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735079657; x=1735338857; bh=myTo5eq6HOWFrTaVdioRjiU5COHmVyu47RCrhgDPjvE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=T8RXKJmNdqCGch8Ds2TxnHI8QcVqXwAiEjK2R11gPkTXMwguApNlOlJWzkNOJa/zD vJykrO3/E2KJBk3yRTBKIZOjHFs71NyybsLLUjxTLOEgBnCJn5pVEA13m0pMBL/lZI BbMG67JtJwHPpn22igQifGTKdhDqWZoNV6W/OEcVTZy6kFTdwu5vTueV09VJTcNOAF ufMSh5WCT/+l0aA4Dg83tqn3iOyd21ZlgETv9NRc0BMrKyZhGqD/rjtB5ZeG9OPrgg I3zgoXfoczDg5lPTiAkRQXqg4kYL3A77ZXR7+jWt+MdLIx5W3ZWt4nzwJ7MawNvY7V 8IDSvkFLKWtxg== In-Reply-To: <87a5cnw6w4.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: acd96f6a63447f934e7cf8a7835bfca6f1144353 Received-SPF: pass client-ip=79.135.106.30; envelope-from=pipcet@protonmail.com; helo=mail-10630.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 24 Dec 2024 22:20:46 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327045 Archived-At: =C3=93scar Fuentes writes: > Pip Cet writes: > >>> Redisplay just stopped while showing the menu, no crash nor infinite >>> loop, its CPU usage was typical for the repeating timers that my config >>> creates. >> >> That's a bit odd. It might be the signal issue, but that's purely a >> guess. If it happens again, please let us know. > > Sure. I'm not a hundred percent sure, because I was testing other changes, but I just observed an Emacs session in a very similar state to what you describe: very little but nonzero CPU usage, but unresponsive to X interactions. I attached gdb, observed it was stuck in read_char, then I messed up and set Vquit_flag to Qt, at which point the Emacs session recovered and seems fully usable once more (it did take a while to do so, though). So no valuable debug info this time, hope I'll hit it again. Again, it's possible this is a similar-looking but different bug, possibly caused by local changes. I don't think read_char or its subroutines even use MPS memory, though? As this is a GTK build, and yours wasn't, we should probably look at X interaction code shared between the GTK and non-GTK builds. Pip