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?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Freezing frame with igc Date: Wed, 25 Dec 2024 05:25:06 +0100 Message-ID: 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="37232"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , emacs-devel@gnu.org, Helmut Eller , Andrea Corallo To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 05:26:10 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 1tQIyH-0009UQ-0v for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 05:26:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQIxP-0001c9-LM; Tue, 24 Dec 2024 23:25:15 -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 1tQIxO-0001bz-CF for emacs-devel@gnu.org; Tue, 24 Dec 2024 23:25:14 -0500 Original-Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tQIxM-0004rB-LA; Tue, 24 Dec 2024 23:25:14 -0500 Original-Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5d3e9a88793so9634251a12.1; Tue, 24 Dec 2024 20:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735100709; x=1735705509; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=fSsZBV0tE6lClY91yxnG7WhG0U2uhRjNdM/c2Yk3oIs=; b=AedvVMRH5bFVuqT2FC4+0DMd9ZKfWBy3JyIr8ibFkR1ZpBxgZotkXQRjVExSRS24k2 XrigogIV3R9qg5jQMJHR9knhwh4/qTadk3+0xv2XkSkNfK8/39sKzquk9Sbr1bnksXCv lSAy3q1PE2fmS1nd6HY+milxGj1HmTrA32kgbH3mnwHZJCb7aU/CCoq5VVFl16rcIYMQ 11wOVJlqsezVdbz5yjQVppq6lzrg1eb9qeaLk/qtv/qJearQUGZ8tgeBybTMlSuatbm0 pO5hBZyLkevKfUQ1xourBJPoeJLda6GlX9SXDlVWvf/t0cFotfVIq9Siloz2fKM794S7 DOuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735100709; x=1735705509; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=fSsZBV0tE6lClY91yxnG7WhG0U2uhRjNdM/c2Yk3oIs=; b=MPxKX4l0plyXeqV9J5M++INhUMLyaoM4483+v0ReCR1+Eg4dhF/ykQBde3pDyh5waM 0yG/c7Dmv/lFoObyc3ylmcsavLStgueUKd4kdcjvN3LVPZhVguerXueMxwah2e88OOcD iLLj6us6MbKBWPDgU1ceUaP2Gw3+gGjc+cTyj+akPIGftzZF0vo/l0EwKu0o4XIMSqf7 jAQcdtnMmRX7voOT1l+hzM82AGB5IAGjEN67hV8LF157du1BDrdbPywwkTsQ8zOIwuuL ZxOiEVy7q5ivkv0Ojft6af2vzjRSlT0F6bF5EbZjKx6+7qrZ+G4aoDaGlN3VRWj9IO2R ynUA== X-Forwarded-Encrypted: i=1; AJvYcCU9l8hGrSKPulIWCqunYZb8t4JJl41XcYDWYJmxoC7Z6NH2EtsVL7BqBIzhg4SP60tANEp+JZXw9Q==@gnu.org, AJvYcCXW7TK/SUqvqnugni8DOdbEM5jYpCP7Mpt62yK6hJltoREbe+jZug1tGaUylwqcaS4TurBg/hEqdwBRwHc=@gnu.org X-Gm-Message-State: AOJu0Yzgk9+5N+LmUj7AlJl0+ta4yOzoDgnh9IppYZs7PqAL7Vydqteb NWeE9HSjg6TGkiSIFtD2IPIn3vqYvrozmqBy5Vs0Wn14jtDfKpQJbjhWrw== X-Gm-Gg: ASbGncvFgAWeHtx5xFz2jOyOHU/y05YIVPZ9dwiZ1ONn2CjZYK0reXA7nDVZvftkcNH +9qXijaitPlgEd8Y2Az3M6/z4wXHL25rdAGeHLUr5JyCxjnxNb8rT+TU+oqpDEk1VwI0v3B5h42 mf6I9ONpNqgQcIq/y/1eKReqlLaVXc7pfa8yKfEVYIq5zBoyvALOnio5zbU/HrWK9lHX2codKsf AjIltiytP7ovGn6SwzLZE2Xs25inBHbDHrWbaEhSDVS09PAgBw/hgh+JQULpDz8BEhgSW8bd4PZ LCb2jSipFtbne7IiEPyQbEs7UJeaeEhzF7E5F40CC5CW8oCgtAdWYHI0PT8B X-Google-Smtp-Source: AGHT+IHTCelv2BvVZFXbaMr9bNVh3AH9XcCpe9D9y/8mPL2T/t0jYKIo/XVLHlLZ8nOjMxy50keCtQ== X-Received: by 2002:a05:6402:354c:b0:5d4:35c7:cd7c with SMTP id 4fb4d7f45d1cf-5d81ddfd836mr14445906a12.26.1735100709334; Tue, 24 Dec 2024 20:25:09 -0800 (PST) Original-Received: from pro2 (p200300e0b73d6f00401d1c7c2fc22e2d.dip0.t-ipconnect.de. [2003:e0:b73d:6f00:401d:1c7c:2fc2:2e2d]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d806fed4d5sm7207774a12.65.2024.12.24.20.25.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Dec 2024 20:25:08 -0800 (PST) In-Reply-To: <87msgkaeyy.fsf@protonmail.com> (Pip Cet's message of "Tue, 24 Dec 2024 22:34:12 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52b.google.com 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:327049 Archived-At: (Subject changed.) Pip Cet writes: > =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 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. /* We want to make sure that the next event generates a frame-switch event to the appropriate frame. This seems kludgy to me, but before you take it out, make sure that evaluating something like (select-window (frame-root-window (make-frame))) doesn't end up with your typing being interpreted in the new frame instead of the one you're actually typing in. */ /* FIXME/tty: I don't understand this. (The comment above is from Jim BLandy 1993 BTW, and the frame_ancestor_p from 2017.) Setting the last event frame to nil leads to switch-frame events being generated even if they normally wouldn't be because the frame in question equals selected-frame. See the places in keyboard.c where make_lispy_switch_frame is called. This leads to problems at least on ttys. Imagine that we have functions in post-command-hook that use select-frame in some way (e.g., with-selected-window). Let these functions select different frames during the execution of post-command-hook in command_loop_1. Setting internal_last_event_frame to nil here makes these select-frame calls (potentially and in reality) generate switch-frame events. (But only in one direction (frame_ancestor_p), which I also don't understand). These switch-frame events form an endless loop in command_loop_1. It runs post-command-hook, which generates switch-frame events, which command_loop_1 finds (bound to '#ignore) and executes, which again runs post-command-hook etc., ad infinitum. Let's not do that for now on ttys. */