From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Freezing frame with igc Date: Wed, 25 Dec 2024 12:55:15 +0100 Message-ID: <87wmfougd8.fsf@telefonica.net> References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87h66vwn1m.fsf@telefonica.net> <87y107e02u.fsf@protonmail.com> <87a5cnw6w4.fsf@telefonica.net> <87msgkaeyy.fsf@protonmail.com> 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="3058"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Pip Cet , emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 12:56:22 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 1tQPzx-0000gV-TO for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 12:56:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQPzO-0007TU-IN; Wed, 25 Dec 2024 06:55:46 -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 1tQPzN-0007TL-GA for emacs-devel@gnu.org; Wed, 25 Dec 2024 06:55:45 -0500 Original-Received: from relayout02.e.movistar.es ([86.109.101.202] helo=relayout02-redir.e.movistar.es) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQPzL-0003ET-KI for emacs-devel@gnu.org; Wed, 25 Dec 2024 06:55:45 -0500 Original-Received: from sky (26.red-81-39-22.dynamicip.rima-tde.net [81.39.22.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4YJ9Dg74LYzdZQw; Wed, 25 Dec 2024 12:55:15 +0100 (CET) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann?= =?utf-8?Q?=22's?= message of "Wed, 25 Dec 2024 05:25:06 +0100") X-TnetOut-Country: IP: 81.39.22.26 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4YJ9Dg74LYzdZQw.A5B18 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1735732516.48421@8kfpPFjLsLTd4c7bBe6JBw Received-SPF: softfail client-ip=86.109.101.202; envelope-from=ofv@wanadoo.es; helo=relayout02-redir.e.movistar.es X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no X-Spam_action: no action 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:327074 Archived-At: (CC list trimmed) Gerd M=C3=B6llmann writes: >>>>> Redisplay just stopped while showing the menu, no crash nor infinite >>>>> loop, its CPU usage was typical for the repeating timers that my conf= ig >>>>> 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 > > That reminds of something. Maybe what you've seen is completely > unrelated, it's impossible to tell, but please find below a comment that > I added to do_switch_frame in frame.c. [snip] At the time I was working with two frames. The frame where I tried to show the menu went blank. I use mini-echo [1], which removes the mode line and uses the echo area instead, periodically (0.3 seconds) updating the echo area (it has a cache for not updating when there are no changes, but my experience is that the updates are very frequent.) So it could be that mini-echo tried to update the echo area (of both frames, because it shows the same text on all frames) at an "unfortunate time" while the menu was being displayed. I don't know if this hypothesis even makes sense. BTW, I'm fairly sure that mini-echo was the responsible of the small CPU activity I saw on htop after Emacs UI froze. 1. https://github.com/liuyinz/mini-echo.el