From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#75461: 30.0.93; Frequent (but inconsistent) hangs when creating frames Date: Thu, 09 Jan 2025 15:12:43 +0200 Message-ID: <86zfk0167o.fsf@gnu.org> References: <05bdbaa416fc63c8ee1d06ade53c2f60@webmail.orcon.net.nz> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33172"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75461@debbugs.gnu.org To: Phil Sainty Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 09 14:13:19 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tVsLf-0008PI-38 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Jan 2025 14:13:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVsLQ-0000tc-OS; Thu, 09 Jan 2025 08:13:04 -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 1tVsLP-0000t9-EM for bug-gnu-emacs@gnu.org; Thu, 09 Jan 2025 08:13:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tVsLP-0004bg-5X for bug-gnu-emacs@gnu.org; Thu, 09 Jan 2025 08:13:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=sNznp2TDNt358ksnZuNMcRI6ihnDDPPJ3lTfEf3CMvk=; b=NZgawrny9xqD0e1F5ulOwjfJ5K/kv9l2Te9DOG9fyV3EBB4wrmLwTahZ9K7SVo85MIQIuhXzoTuoWnCtZ4Ry4WO8WC42TQSMeLf5RrUHu1rfyCEgiSGo6CCiXzu0ikqBJNmTdyQ63G0HXJJ8mDFNaevEjy/FOlDb1ZBWdQ1vKAAZ/kek5FFVqwmSOmPohzLEMpbzs/Dhx5dS5hwUaXGqKtuxozoAHH+yZA5GvE3txqvXZ6JwOv9hkXZwisdaFcUz5sNG5JDIRIG0khsMqxsUad8lKLGTUK4t7daobzjjL43/XybEP4mAqv/tOAJmN/JLNcv7mf7K/7Sr7HUAnwbADw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tVsLO-00074m-G4 for bug-gnu-emacs@gnu.org; Thu, 09 Jan 2025 08:13:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Jan 2025 13:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75461 X-GNU-PR-Package: emacs Original-Received: via spool by 75461-submit@debbugs.gnu.org id=B75461.173642837627186 (code B ref 75461); Thu, 09 Jan 2025 13:13:02 +0000 Original-Received: (at 75461) by debbugs.gnu.org; 9 Jan 2025 13:12:56 +0000 Original-Received: from localhost ([127.0.0.1]:50831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVsLH-00074P-Ki for submit@debbugs.gnu.org; Thu, 09 Jan 2025 08:12:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50058) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVsLF-00074A-Ek for 75461@debbugs.gnu.org; Thu, 09 Jan 2025 08:12:54 -0500 Original-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 ) id 1tVsL7-0004Yj-MB; Thu, 09 Jan 2025 08:12:46 -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=sNznp2TDNt358ksnZuNMcRI6ihnDDPPJ3lTfEf3CMvk=; b=UFX527owtuK6 ihUzU4UcXSkkVAq9E8mOA9nWlHhoY9/3parQBK3c+xs6b5ay+2oW5KZ4THp8aBBhg5betGgc/Q8R1 0+EFcS8TsMYLV4i7y9667nBi62xxYFSSrXTaNm8cKau1Rd7hGn9MiAFW3V2lli4HNyLmKxG/3CDS6 WXVWIX3K+KlbYtUKa6ZCtXa6oVWAGJBbApu/SG934j644ES3tEZxlOXPv0FH6fL1L5mgd1RNASLcm xNYlrzBFQeTfQRCrxeND1WuIaNHdUY/v+pILbJ8KCKGDhNYFasN25CaW7lcKO6ys4+CAbPtcDm3S5 PuFxosXwgr0Rq2gCNozhcA==; In-Reply-To: <05bdbaa416fc63c8ee1d06ade53c2f60@webmail.orcon.net.nz> (message from Phil Sainty on Fri, 10 Jan 2025 01:09:20 +1300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298834 Archived-At: > Date: Fri, 10 Jan 2025 01:09:20 +1300 > From: Phil Sainty > > I've recently switched my main instance of Emacs to 30.0 (firstly > 30.0.93, and now the HEAD of the emacs-30 branch), and I've been > experiencing frequent hangs (with the CPU core spinning at 100% usage) > when creating new frames. > > More specifically: when creating frames using a system I use with my > window manager when I want to interactively select a thing in a pop-up > Emacs frame. (I've tried to replicate this with simply "C-x 5 2" but > didn't manage to do so thus far.) > > If I spam a terminal with a large number of "kill -USR2 " commands > for the spinning Emacs process ID, then I'll get control back. > > I'm experiencing this (inconsistently, but quite often) with using a > keybinding for my window manager (XMonad), which runs a command like: > > emacsclient --eval "(my-x-paste-example $(xdotool getactivewindow))" > > With that command being something like: > > (defun my-x-paste-example (wid) > (interactive) > (my-x-paste #'my-example wid "*Example*" "Testing")) > > (defun my-example () > (interactive) > (gui-backend-set-selection > 'CLIPBOARD (completing-read "Choose: " '(one two three)))) > > I've attached the definition of `my-x-paste' to this report. It > creates a small floating frame for the interaction, and afterwards it > runs xdotool again to paste the clipboard contents into the X window > obtained by "xdotool getactivewindow", but I think the xdotool aspect > shouldn't be a factor, as it never gets that far -- Emacs creates the > frame and then immediately hangs before I can interact with it at all. > Perhaps the frame parameters used in that function are relevant, > though. > > I've recompiled Emacs for debugging and run it under gdb, and have > reproduced a hang, so I have also attached some backtraces from gdb > (more than one because they're variable). In each case I used > "kill -TSTP " to stop Emacs spinning and drop to the gdb prompt, > and then the "backtrace" command. I then had to "continue" multiple > times before Emacs started running/spinning again, after which I > repeated the process. > > (I also tried "xbacktrace" but that just said "Undefined command: > "xbacktrace". Try "help".", and I'm afraid that I only just saw the > "bt full" recommendation in the report-emacs-bug template -- the > etc/DEBUG file doesn't actually mention that command -- and I've not > been able to reproduce the issue in the interim to try that one, so > I'm sending this as-is for now.) > > The function I'm calling in lisp does a `completing-read', and I can > see Fread_from_minibuffer in the backtrace, so I *guess* it's getting > that far after creating the frame; but I'm not sure if that's a factor > as (I think) I've also seen this with a pop-up notification frame > I use for appt.el notifications -- and that one doesn't prompt me at > all (but it's creating frames in a fairly similar way). > > I can't replicate this at will, but it happens often enough that I > *should* be able to recreate it again sometime soon, so let me know > if you want me to try other things (but note that I'm not familiar > with gdb and debugging C code, so step-by-step instructions will be > helpful for that). Run Emacs normally, not from GD, and when it hangs attach GDB to it and say (gdb) thread apply all bt Then post here everything GDB produces. (It is best to run GDB from the src directory of the Emacs source tree, where it will read the .gdbinit file which helps displaying Lisp objects.) If we don't see from the first backtrace you produce what is the problem, then do the above several times, so we could see some pattern of where it hangs. Btw, by "hangs" you mean it is stuck doing nothing, right? It doesn't use 100% of some CPU execution unit (that would be "infloops", not "hangs"), right?