From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 06:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 79367@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.175679403427118 (code B ref -1); Tue, 02 Sep 2025 06:21:01 +0000 Received: (at submit) by debbugs.gnu.org; 2 Sep 2025 06:20:34 +0000 Received: from localhost ([127.0.0.1]:59510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utKNZ-00073G-FM for submit@debbugs.gnu.org; Tue, 02 Sep 2025 02:20:33 -0400 Received: from lists.gnu.org ([2001:470:142::17]:60216) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utKNS-0006wy-U6 for submit@debbugs.gnu.org; Tue, 02 Sep 2025 02:20:27 -0400 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 1utKMp-0004Zj-GM for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2025 02:19:54 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1utKMf-0005ax-KJ for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2025 02:19:39 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 7641543A8A for ; Tue, 2 Sep 2025 06:19:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1756793968; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=MtdTz2bSu+ZXnp/xHE5etOqHiaw9q+43Y3DRzbyGfH4=; b=MRKfOVi0/VriuJyG3kpOAQtP+7uSmCefSeQkpY+cCLcJCqm7RW1he3OvVJHloX/QMWA1Bb o29VIhxa/uNB5uTRJ1OB7wPRZa/6DdJd0ZrFQxbK7AAlaFbe83IUZbb4OAwEXrZyNnJy3E cNpuFeplRbtljuPJ8F3mbOF9S47WcCL5Id/bXCJy2alWJUjsgpSAR8OPnF2PlHO9GmbQad Qvr5pfnWrHmnCwMqYTvqFHgOlReu1Zqosv918XIemewjWdAQ9GYbfKTOGiZ1piiGXalLIP xIF1Op9AzPRPfhA2V+YLeXOcjWKOfp+lW3PfHFavNZStRYX6G3/1ORVdUWTWQA== From: Zhengyi Fu Date: Tue, 02 Sep 2025 14:18:58 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: 0 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduleegvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkfggtgesthdtredttddttdenucfhrhhomhepkghhvghnghihihcuhfhuuceoihesfhhuiiihrdhmvgeqnecuggftrfgrthhtvghrnhepueefveekueeuueekkeegjeekveefvdetffetuefhffdtheelgfeiteekvddtleejnecuffhomhgrihhnpehhphhitghorhhprdhnvghtnecukfhppeduledvrdehiedrleelrdduvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduledvrdehiedrleelrdduvddphhgvlhhopehjrghmvghsqdhfuhdquhgsuhhnthhuvdegtdegpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepuddprhgtphhtthhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnhhurdhorhhg X-GND-Sasl: id@fuzy.me Received-SPF: pass client-ip=217.70.183.193; envelope-from=i@fuzy.me; helo=relay1-d.mail.gandi.net X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Hi Emacs maintainers, I have been suffering from this bug for a few weeks. I spent a few days finding minimal steps to reproduce the bug: - Install diff-hl and magit - Set `diff-hl-update-async' to t and enable global-diff-hl-mode - Enable server-mode - Open a file in a git repo, make some changes and save it - Run `magit-stage-buffer-file' to stage the changes - Run `revert-buffer' in the file buffer, and make sure the diff-hl fringes are displayed - Run `magit-commit-create' At this moment, a COMMIT_EDITMSG buffer should appear. But actually sometimes no buffer appears. If you run `list-processes', you can see that the git process and the server connection are all there, as shown below. git 542014 run magit-process: emacs_test /dev/pts/1 Main git --no-pager --literal-pathspecs -c core.preloadindex=true -c log.showSignature=false -c color.ui=false -c color.diff=false -c diff.noPrefix=false commit -- server -- listen -- -- Main (network server on /run/user/150425139/emacs/server) server <2> -- open -- -- Main (network connection to t:/run/user/150425139/emacs/server) The commit message buffer will pop up, if you eval (set-process-thread (get-process "server <2>") nil) Further debugging through gdb revealed more details: the `thread' member of the fd_callback_info entry for the server connection references the diff-hl-async thread, which is already exited. Simply adding a `set_proc_thread' in `server_accept_connections' like the following seems to resolve the issue, but I'm not sure if this is the correct fix. diff --git a/src/process.c b/src/process.c index d6efac5479d..326a36716d5 100644 --- a/src/process.c +++ b/src/process.c @@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel) /* Client processes for accepted connections are not stopped initially. */ if (!EQ (p->filter, Qt)) add_process_read_fd (s); + set_proc_thread (p, current_thread); + if (s > max_desc) max_desc = s; In GNU Emacs 31.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.41) of 2025-09-02 built on james-fu-ubuntu2404 Repository revision: b953dc679c53d8ae26770762bcb2601389146768 Repository branch: heads/master Windowing system distributor 'Microsoft Corporation', version 11.0.12010000 System Description: Ubuntu 24.04.3 LTS Configured using: 'configure --without-all --with-threads --enable-checking 'CFLAGS=-O1 -ggdb3 -pipe'' Configured features: GLIB GMP PDUMPER SECCOMP THREADS X11 XIM XINERAMA XRANDR GTK3 Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: global-git-commit-mode: t magit-auto-revert-mode: t auto-revert-mode: t server-mode: t global-diff-hl-mode: t diff-hl-mode: t straight-use-package-mode: t straight-package-neutering-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /var/lib/domain_home/auth.hpicorp.net/fujames/.config/emacs/straight/build/transient/transient hides /var/lib/domain_home/auth.hpicorp.net/fujames/src/emacs_test/lisp/transient /var/lib/domain_home/auth.hpicorp.net/fujames/.config/emacs/straight/build/seq/seq hides /var/lib/domain_home/auth.hpicorp.net/fujames/src/emacs_test/lisp/emacs-lisp/seq /var/lib/domain_home/auth.hpicorp.net/fujames/.config/emacs/straight/build/compat/compat hides /var/lib/domain_home/auth.hpicorp.net/fujames/src/emacs_test/lisp/emacs-lisp/compat Features: (shadow sort mail-extr emacsbug lisp-mnt bug-reference thingatpt help-fns radix-tree cl-print debug backtrace find-func display-line-numbers face-remap magit-submodule magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit package url-handlers magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode diff git-commit magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor shell pcomplete comint ansi-osc ansi-color magit-mode transient pp edmacro kmacro browse-url xdg url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util url-parse auth-source icons json map url-vars benchmark magit-git magit-base magit-section format-spec cursor-sensor crm llama eieio byte-opt eieio-core cond-let compat server vc-git files-x diff-hl log-view log-edit message sendmail mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader ring add-log pcvs-util vc-dir ewoc vc vc-dispatcher diff-mode track-changes easy-mmode magit-autoloads pcase with-editor-autoloads transient-autoloads magit-section-autoloads llama-autoloads cond-let-autoloads compat-autoloads info seq-autoloads diff-hl-autoloads finder-inf straight-autoloads cl-seq cl-extra help-mode straight subr-x cl-macs gv cl-loaddefs cl-lib bytecomp byte-compile rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dynamic-setting gtk x-toolkit x multi-tty move-toolbar make-network-process tty-child-frames emacs) Memory information: ((conses 16 161628 25408) (symbols 48 16281 0) (strings 32 52533 3112) (string-bytes 1 1564345) (vectors 16 32763) (vector-slots 8 308800 12722) (floats 8 75 448) (intervals 56 559 0) (buffers 984 21)) From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 12:34:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Zhengyi Fu , Spencer Baugh , Dmitry Gutov Cc: 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175681643427108 (code B ref 79367); Tue, 02 Sep 2025 12:34:03 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 12:33:54 +0000 Received: from localhost ([127.0.0.1]:32970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utQCw-000734-1L for submit@debbugs.gnu.org; Tue, 02 Sep 2025 08:33:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52850) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utQCp-00071g-6g for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 08:33:48 -0400 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 1utQCc-0008Hb-Iz; Tue, 02 Sep 2025 08:33:34 -0400 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=1ZIs1HJe88MQz2NjtSDsduDQ4t0hWUsLq8rVUOw/s3c=; b=LactVXqKRuWs 35XdhJGRKrjMm+9QNlIN8E74lfTzlCXDVy9HIUFaJK1n0inYzCHHVHZHcYYvZbOxuKkCbF8Rs4JOh jjcXySg0pv76L1NgTD0M/9PFneJNZjrjnEwd9T/4vGoSfBi/v1Xp7GP5pNy6Oj4vqv7itd9jEq3YL Jf/HR3kjntcOepHBHCoudp7SIWZPzBLHWzyqGGhzKFGMJtDba/aTcRFoR2VNZ9B4ulp4nxerXSaZU UOxLHI4tUh9Us82NP/5MwAvT7ZZdq6nZYiL3u8UWBlGgkBdIyiLwZDeGVpfYOAuo6m1kQVLgytPo6 ZoGTJVi/Sq1nEr9qZMHIHQ==; Date: Tue, 02 Sep 2025 15:32:57 +0300 Message-Id: <865xe1m3uu.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Zhengyi Fu on Tue, 02 Sep 2025 14:18:58 +0800) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zhengyi Fu > Date: Tue, 02 Sep 2025 14:18:58 +0800 > > Hi Emacs maintainers, > > I have been suffering from this bug for a few weeks. > > I spent a few days finding minimal steps to reproduce the bug: > > - Install diff-hl and magit > - Set `diff-hl-update-async' to t and enable global-diff-hl-mode > - Enable server-mode > > - Open a file in a git repo, make some changes and save it > - Run `magit-stage-buffer-file' to stage the changes > - Run `revert-buffer' in the file buffer, and make sure the diff-hl > fringes are displayed > - Run `magit-commit-create' > > At this moment, a COMMIT_EDITMSG buffer should appear. But actually > sometimes no buffer appears. > > If you run `list-processes', you can see that the git process and the > server connection are all there, as shown below. > > git 542014 run magit-process: emacs_test /dev/pts/1 Main git --no-pager --literal-pathspecs -c core.preloadindex=true -c log.showSignature=false -c color.ui=false -c color.diff=false -c diff.noPrefix=false commit -- > server -- listen -- -- Main (network server on /run/user/150425139/emacs/server) > server <2> -- open -- -- Main (network connection to t:/run/user/150425139/emacs/server) > > > The commit message buffer will pop up, if you eval > (set-process-thread (get-process "server <2>") nil) > > Further debugging through gdb revealed more details: the `thread' > member of the fd_callback_info entry for the server connection > references the diff-hl-async thread, which is already exited. > > Simply adding a `set_proc_thread' in `server_accept_connections' like > the following seems to resolve the issue, but I'm not sure if this is > the correct fix. > > diff --git a/src/process.c b/src/process.c > index d6efac5479d..326a36716d5 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel) > /* Client processes for accepted connections are not stopped initially. */ > if (!EQ (p->filter, Qt)) > add_process_read_fd (s); > + set_proc_thread (p, current_thread); > + > if (s > max_desc) > max_desc = s; Thanks. I believe you are right, since server_accept_connection calls make_process to create a new process object, which should by default be locked to the thread which created it. Spencer and Dmitry, do you agree? From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 13:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Zhengyi Fu , Dmitry Gutov , 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17568185058514 (code B ref 79367); Tue, 02 Sep 2025 13:09:02 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 13:08:25 +0000 Received: from localhost ([127.0.0.1]:33431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utQkL-0002DG-5o for submit@debbugs.gnu.org; Tue, 02 Sep 2025 09:08:25 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:50163) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utQkG-0002Cv-IO for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 09:08:22 -0400 From: Spencer Baugh In-Reply-To: <865xe1m3uu.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Sep 2025 15:32:57 +0300") References: <865xe1m3uu.fsf@gnu.org> Date: Tue, 02 Sep 2025 09:08:14 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756818494; bh=oCYIDwKdr/vQrWruQLLGNssPG16Pe+4teGs224A8qNI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=qVNRFf9s/YxVQSfKjspJqaQh8PCpYxWACy4pocRm/aCs2BlEOsca9BfHRhWWXBwCQ t/W8YZFZrmIa/qG1X5Prg6UmZNK4Zxefmvu48XzQG9N007OeJjdbZl98ka28hFsYGk koa4EWOtd5HhEA47bl8JFrnDl1zbPw0/3THYCFSGSoyBy6KvFCHdgFAOCjeA5eSfP6 Etc+UlyeEKmZUzcwvyNERw+onk2ILQ5lrBuyniZkD8FLD1p29ZrZeYhP1UACYKSGF8 932heo8PuBsE1nUHB3bLyXme7jbqYP4p3wZA5E8FmrrbQysqWRBqSL+AcdEdBRb3XU sAvu9oB/xvZhA== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Zhengyi Fu >> Date: Tue, 02 Sep 2025 14:18:58 +0800 >> >> Hi Emacs maintainers, >> >> I have been suffering from this bug for a few weeks. >> >> I spent a few days finding minimal steps to reproduce the bug: >> >> - Install diff-hl and magit >> - Set `diff-hl-update-async' to t and enable global-diff-hl-mode >> - Enable server-mode >> >> - Open a file in a git repo, make some changes and save it >> - Run `magit-stage-buffer-file' to stage the changes >> - Run `revert-buffer' in the file buffer, and make sure the diff-hl >> fringes are displayed >> - Run `magit-commit-create' >> >> At this moment, a COMMIT_EDITMSG buffer should appear. But actually >> sometimes no buffer appears. >> >> If you run `list-processes', you can see that the git process and the >> server connection are all there, as shown below. >> >> git 542014 run magit-process: emacs_test /dev/pts/1 Main git --no-pager --literal-pathspecs -c core.preloadindex=true -c log.showSignature=false -c color.ui=false -c color.diff=false -c diff.noPrefix=false commit -- >> server -- listen -- -- Main (network server on /run/user/150425139/emacs/server) >> server <2> -- open -- -- Main (network connection to t:/run/user/150425139/emacs/server) >> >> >> The commit message buffer will pop up, if you eval >> (set-process-thread (get-process "server <2>") nil) >> >> Further debugging through gdb revealed more details: the `thread' >> member of the fd_callback_info entry for the server connection >> references the diff-hl-async thread, which is already exited. >> >> Simply adding a `set_proc_thread' in `server_accept_connections' like >> the following seems to resolve the issue, but I'm not sure if this is >> the correct fix. >> >> diff --git a/src/process.c b/src/process.c >> index d6efac5479d..326a36716d5 100644 >> --- a/src/process.c >> +++ b/src/process.c >> @@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel) >> /* Client processes for accepted connections are not stopped initially. */ >> if (!EQ (p->filter, Qt)) >> add_process_read_fd (s); >> + set_proc_thread (p, current_thread); >> + >> if (s > max_desc) >> max_desc = s; > > Thanks. > > I believe you are right, since server_accept_connection calls > make_process to create a new process object, which should by default > be locked to the thread which created it. > > Spencer and Dmitry, do you agree? No. At worst, the locking of the new connection should match that of the existing process. The new connection should not randomly be locked to the thread which happened to run wait_reading_process_output. >> Further debugging through gdb revealed more details: the `thread' >> member of the fd_callback_info entry for the server connection >> references the diff-hl-async thread, which is already exited. This aspect sounds similar to bug#79201. Zhengyi, I assume you're testing with an Emacs built from source. Can you check whether the Emacs you're building includes commit 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple weeks ago? If not, can you pull and test again? If that doesn't fix it (or you already had that commit), can you try reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then c93be71e45d4cebeb017c813426228e579e9381d and test again? From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 13:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: Dmitry Gutov , Eli Zaretskii , 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175682083417812 (code B ref 79367); Tue, 02 Sep 2025 13:48:02 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 13:47:14 +0000 Received: from localhost ([127.0.0.1]:33789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utRLt-0004dE-I6 for submit@debbugs.gnu.org; Tue, 02 Sep 2025 09:47:13 -0400 Received: from relay5-d.mail.gandi.net ([2001:4b98:dc4:8::225]:40821) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utRLo-0004cQ-4o for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 09:47:08 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 3846D43272; Tue, 2 Sep 2025 13:46:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1756820821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B/cyTuy8hu3EhroWJc2FasSP3hIahDWZmPlnE+vTD4g=; b=VxvhzerPvZLf+LUTcbay7CeL/JiGx0ZNpmRoBd33Vwq0WiSYypZfhXl4YWvYY/OIL/XROX ukyxePo96ryQGHp16V1gCUCg9Toy8imQjowXyZQL6Uxi/RseUY2A1dEYmPo+4bjLAn5ext p0dbVsMjGNIQ3yUR6VWbSHHzhc8chFlsqKdQWA57m3vfcWzlLSAcZtzzZhWw2yDTnF9xm+ twlCgg2AUh6iqz+73aGFvZ8mqzoVTgiN5c6X9rMNzP/PLUWPmMEcR2MEHd76Y2Afscx9ef eac5ZVvWu4rFF7EmaruD12w8swAK+PaGft5kGPqgvVh4LDEUCMEYsX2BNfdtzQ== From: Zhengyi Fu In-Reply-To: References: <865xe1m3uu.fsf@gnu.org> Date: Tue, 02 Sep 2025 21:46:56 +0800 Message-ID: <8734950xwv.fsf@fuzy.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdegvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghffffkfgggtgesthdtredttdertdenucfhrhhomhepkghhvghnghihihcuhfhuuceoihesfhhuiiihrdhmvgeqnecuggftrfgrthhtvghrnheptedvueevffejudfgtdejuefgjeejgedtkeetfefftdeggfffteffieeuhfdtgeefnecukfhppeeghedrkedrudekiedruddtvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeghedrkedrudekiedruddtvddphhgvlhhopegtrghllhhiohhpvgdpmhgrihhlfhhrohhmpehisehfuhiihidrmhgvpdhnsggprhgtphhtthhopeegpdhrtghpthhtohepjeelfeeijeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopegumhhithhrhiesghhuthhovhdruggvvhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhm X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Spencer Baugh writes: >> >> Spencer and Dmitry, do you agree? > > No. At worst, the locking of the new connection should match that of > the existing process. The new connection should not randomly be locked > to the thread which happened to run wait_reading_process_output. > >>> Further debugging through gdb revealed more details: the `thread' >>> member of the fd_callback_info entry for the server connection >>> references the diff-hl-async thread, which is already exited. > > This aspect sounds similar to bug#79201. > > Zhengyi, I assume you're testing with an Emacs built from source. Can > you check whether the Emacs you're building includes commit > 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple > weeks ago? If not, can you pull and test again? Yes, it includes that commit. > If that doesn't fix it (or you already had that commit), can you try > reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then > c93be71e45d4cebeb017c813426228e579e9381d and test again? After reverting those two commits, it worked fine. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 13:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Zhengyi Fu Cc: Dmitry Gutov , Eli Zaretskii , 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175682141821554 (code B ref 79367); Tue, 02 Sep 2025 13:57:02 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 13:56:58 +0000 Received: from localhost ([127.0.0.1]:34883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utRVJ-0005bY-Mv for submit@debbugs.gnu.org; Tue, 02 Sep 2025 09:56:58 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:46927) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utRVF-0005ah-Se for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 09:56:54 -0400 From: Spencer Baugh In-Reply-To: <8734950xwv.fsf@fuzy.me> (Zhengyi Fu's message of "Tue, 02 Sep 2025 21:46:56 +0800") References: <865xe1m3uu.fsf@gnu.org> <8734950xwv.fsf@fuzy.me> Date: Tue, 02 Sep 2025 09:56:47 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756821407; bh=och3m/30ExQmqqIyibwY3oQnJLIySWkR9EioUYTtZos=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=nYKzPdOdVpYqhXCI15liYA5SM5mIzXoW+ZY+9CAxnZeFKPZcXoW1K+TK/XpY4Imbt 88HuNAuhOxbS2c3O2cMdFXv2XqlHTMoFSwqlkZN0BkX8JSCCY2nMUJWGANDJSvsoSv oNW3kWilkEoxdMYjfnDU10NtQAtarFEgn+Yg4uv9PgLxiNjL1QmIaBJJ/tUQnCtB5L vE5TWwwSDeAq3onXBKKzN4BMIXxVZ269LFrICf/nY3xio7XueaxXPa4HP8fZPkDiD7 leVqZqkFJiMIfHqiNd+0lccfLCUXCRx4iaPaWvJjIwe5cjNqLiRQsRO60V9N1BZQ/e MuT1PCu8gP2Bg== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Zhengyi Fu writes: > Spencer Baugh writes: >>>> Further debugging through gdb revealed more details: the `thread' >>>> member of the fd_callback_info entry for the server connection >>>> references the diff-hl-async thread, which is already exited. >> >> This aspect sounds similar to bug#79201. >> >> Zhengyi, I assume you're testing with an Emacs built from source. Can >> you check whether the Emacs you're building includes commit >> 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple >> weeks ago? If not, can you pull and test again? > > Yes, it includes that commit. > >> If that doesn't fix it (or you already had that commit), can you try >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then >> c93be71e45d4cebeb017c813426228e579e9381d and test again? > > After reverting those two commits, it worked fine. Thanks for testing. I believe the right fix is to revert those commits, since they are already breaking existing code using threads. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 14:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175682268230870 (code B ref 79367); Tue, 02 Sep 2025 14:19:01 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 14:18:02 +0000 Received: from localhost ([127.0.0.1]:35114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utRph-00081f-RK for submit@debbugs.gnu.org; Tue, 02 Sep 2025 10:18:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41268) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utRpb-00080u-1d for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 10:17:56 -0400 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 1utRpP-0006MB-Qn; Tue, 02 Sep 2025 10:17:44 -0400 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=7i7nvioY5IhRoyipLEloWwpTkrKZ+tm3UHJcnZsF1uQ=; b=cNF3xDpRAzPk g5slJ48MEJfxIq0mnOfYE/lidQjaJDBo80YubarNgL1IuAPVnyuUTAuGe+xxbzqoPE/PlwXKNlSJ4 yzMG/TxYauMilGjFXEMJetRDiS3BRku7dABHcqER4DS9SQCBDftt7+znhFkDSq8DbL15Xd/4B4bHL sGdRwGKzZMHsG1MiMqGq5XPeS86LIyefx8q0oonHs9jV55t7kJ9++2G6psjEDK5V8OW/4fxBJKZSl 0qEK6wsD+LWoIXVaRXuWoiHAp3NCbB346xlWZNchZiC+86SumHOD+NHbtLFWfzbsa7W/rWupEhUAc RDuiv9m7I71GGo8GoVq0zA==; Date: Tue, 02 Sep 2025 17:17:38 +0300 Message-Id: <863495lz0d.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Tue, 02 Sep 2025 09:08:14 -0400) References: <865xe1m3uu.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Zhengyi Fu , Dmitry Gutov , > 79367@debbugs.gnu.org > Date: Tue, 02 Sep 2025 09:08:14 -0400 > > Eli Zaretskii writes: > > >> --- a/src/process.c > >> +++ b/src/process.c > >> @@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel) > >> /* Client processes for accepted connections are not stopped initially. */ > >> if (!EQ (p->filter, Qt)) > >> add_process_read_fd (s); > >> + set_proc_thread (p, current_thread); > >> + > >> if (s > max_desc) > >> max_desc = s; > > > > Thanks. > > > > I believe you are right, since server_accept_connection calls > > make_process to create a new process object, which should by default > > be locked to the thread which created it. > > > > Spencer and Dmitry, do you agree? > > No. At worst, the locking of the new connection should match that of > the existing process. The new connection should not randomly be locked > to the thread which happened to run wait_reading_process_output. But make_process, called by server_accept_connection, already did this: pset_thread (p, Fcurrent_thread ()); So if we want to lock this new process to some other thread, we should fix that part as well to be consistent. And why do you think this thread is a random one? If everything works as intended, it is the thread which created the existing process, because the descriptor whose presence in Available triggers the call to server_accept_connection is one of those on which pselect waited, and should have belonged to the current thread. If that is not true, then it's a separate problem which should be fixed, perhaps as part of the related discussions. > >> Further debugging through gdb revealed more details: the `thread' > >> member of the fd_callback_info entry for the server connection > >> references the diff-hl-async thread, which is already exited. > > This aspect sounds similar to bug#79201. > > Zhengyi, I assume you're testing with an Emacs built from source. Can > you check whether the Emacs you're building includes commit > 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple > weeks ago? If not, can you pull and test again? > > If that doesn't fix it (or you already had that commit), can you try > reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then > c93be71e45d4cebeb017c813426228e579e9381d and test again? What will that prove? Those changes are not going away, so trying that is just wasting everyone's time and energy. I thought we were past that... From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 14:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17568236034154 (code B ref 79367); Tue, 02 Sep 2025 14:34:02 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 14:33:23 +0000 Received: from localhost ([127.0.0.1]:35276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utS4Y-00014s-Il for submit@debbugs.gnu.org; Tue, 02 Sep 2025 10:33:23 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:43235) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utS4T-000143-SV for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 10:33:19 -0400 From: Spencer Baugh In-Reply-To: <863495lz0d.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Sep 2025 17:17:38 +0300") References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> Date: Tue, 02 Sep 2025 10:33:12 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756823592; bh=k9MUtmnPIR5ICj/I8Xe+qdhOL0yEnADdUZT9WnD46fs=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=wEmMTl1WI0PQ5ZwR2L0Ws98cskKU05z6ee2D1ZT1W5j0lhzvwxPtgMkBRdpXRsLJB Yw+DlhgVuANc2hSV83pwFIerfSrI9ZDcLZI8PnbOCalLwCWlrVR5dOos9jj+KUMEvW 69r5wtwNu8zFILsehqGqQok8uuvJPItqY4Jz3nG2nrdPqp1W4NEBRohTqtVD+FzBoa ESLIgdAIvwaPpwJ1YC6i9Oo1UL6dLQPO2tDgpg1Ec9gzaw2u+AnJLj9Sa5KovWwr+t usNFhm6cdQEChTcC2iWd+fmZMq0T4ft39f9M/RCUNtiOzbmizDtQysrouVlNU2tEV6 JrbZpePsLvBXA== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: Zhengyi Fu , Dmitry Gutov , >> 79367@debbugs.gnu.org >> Date: Tue, 02 Sep 2025 09:08:14 -0400 >> >> Eli Zaretskii writes: >> >> >> --- a/src/process.c >> >> +++ b/src/process.c >> >> @@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel) >> >> /* Client processes for accepted connections are not stopped initially. */ >> >> if (!EQ (p->filter, Qt)) >> >> add_process_read_fd (s); >> >> + set_proc_thread (p, current_thread); >> >> + >> >> if (s > max_desc) >> >> max_desc = s; >> > >> > Thanks. >> > >> > I believe you are right, since server_accept_connection calls >> > make_process to create a new process object, which should by default >> > be locked to the thread which created it. >> > >> > Spencer and Dmitry, do you agree? >> >> No. At worst, the locking of the new connection should match that of >> the existing process. The new connection should not randomly be locked >> to the thread which happened to run wait_reading_process_output. > > But make_process, called by server_accept_connection, already did > this: > > pset_thread (p, Fcurrent_thread ()); > > So if we want to lock this new process to some other thread, we should > fix that part as well to be consistent. True, that's a bug. > And why do you think this thread is a random one? If everything works > as intended, it is the thread which created the existing process, > because the descriptor whose presence in Available triggers the call > to server_accept_connection is one of those on which pselect waited, > and should have belonged to the current thread. Not if the existing process was unlocked. Then this is a random thread. >> >> Further debugging through gdb revealed more details: the `thread' >> >> member of the fd_callback_info entry for the server connection >> >> references the diff-hl-async thread, which is already exited. >> >> This aspect sounds similar to bug#79201. >> >> Zhengyi, I assume you're testing with an Emacs built from source. Can >> you check whether the Emacs you're building includes commit >> 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple >> weeks ago? If not, can you pull and test again? >> >> If that doesn't fix it (or you already had that commit), can you try >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then >> c93be71e45d4cebeb017c813426228e579e9381d and test again? > > What will that prove? Those changes are not going away, so trying > that is just wasting everyone's time and energy. I thought we were > past that... No, we're not past that, I still think those changes are wrong. Especially because this bug report shows that those changes are indeed breaking existing code. I repeatedly said that those changes would cause new issues to be reported, and now it is happening. Maybe it doesn't convince you that the changes need to be reverted, but you should at least be giving it a little more credence now. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 14:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17568242018577 (code B ref 79367); Tue, 02 Sep 2025 14:44:01 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 14:43:21 +0000 Received: from localhost ([127.0.0.1]:35415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utSEC-0002EB-Bl for submit@debbugs.gnu.org; Tue, 02 Sep 2025 10:43:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55694) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utSE8-0002D0-Ea for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 10:43:17 -0400 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 1utSDw-0003Cx-Ur; Tue, 02 Sep 2025 10:43:07 -0400 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=TxQEB62ReXN6bVQbv5D5bC6znRbcwwzZmjaYt+/SBQk=; b=M4PaJ2/hSo2U qztZTVXNTfUY31LWLZQSIz1NaG9I2IOFyPlZDJjbmCbJdKzmv8PWzebaEiSrIwp4ENpkBnwjYdNjs qhei3GFkG26Q2TK3/ZraKX3Cz3dff5l7N/E+qE2c52tZu3GJe879KMw41CjAK0ovyQC8znRMB+VED 30sG0XHJFrzCTgEw1ifOBSJpEqFhaLtnkXjGlYQ3uZWCz6Ee5z6h+/fecPfQB7T43J57sS/XPn4t2 RCEqaGc8VPiFf9ZSXNxsBSPjeCTDFucvzVQhUE3rWHYBHrvMtoHw98CmyN6nzxmTVOX6YZvRfgrMa pOqlb2BtT9jvAu5Ann2bBw==; Date: Tue, 02 Sep 2025 17:42:56 +0300 Message-Id: <86wm6glxu7.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Tue, 02 Sep 2025 09:56:47 -0400) References: <865xe1m3uu.fsf@gnu.org> <8734950xwv.fsf@fuzy.me> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Dmitry Gutov , Eli Zaretskii , > 79367@debbugs.gnu.org > Date: Tue, 02 Sep 2025 09:56:47 -0400 > > Zhengyi Fu writes: > > Spencer Baugh writes: > >>>> Further debugging through gdb revealed more details: the `thread' > >>>> member of the fd_callback_info entry for the server connection > >>>> references the diff-hl-async thread, which is already exited. > >> > >> This aspect sounds similar to bug#79201. > >> > >> Zhengyi, I assume you're testing with an Emacs built from source. Can > >> you check whether the Emacs you're building includes commit > >> 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple > >> weeks ago? If not, can you pull and test again? > > > > Yes, it includes that commit. > > > >> If that doesn't fix it (or you already had that commit), can you try > >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then > >> c93be71e45d4cebeb017c813426228e579e9381d and test again? > > > > After reverting those two commits, it worked fine. > > Thanks for testing. > > I believe the right fix is to revert those commits, since they are > already breaking existing code using threads. I object to doing that, for reasons that were already abundantly discussed. An alternative fix was suggested by the OP that is IMO a step in the right direction. IOW, this scenario reveals yet another call to make_process (which sets the process's 'thread' member, something that was always done there) which isn't followed by marking the I/O descriptors with that same thread. So TRT is to add that missing call to set_proc_thread. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 15:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175682538114718 (code B ref 79367); Tue, 02 Sep 2025 15:03:02 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 15:03:01 +0000 Received: from localhost ([127.0.0.1]:35640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utSXE-0003pH-RN for submit@debbugs.gnu.org; Tue, 02 Sep 2025 11:03:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54456) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utSX8-0003og-Ti for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 11:02:56 -0400 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 1utSX1-0007RL-Fm; Tue, 02 Sep 2025 11:02:48 -0400 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=oPMow9oF0MHZkIIUu2gikRKXgabNUWCoqVdo92V9NDs=; b=bYRIuhD4a77X 1IWJlMtdDU0yCF6GhZvB8dOCzUjYuK0biM6+766O9LwXF488rVsRXHjAcLSm3OeVc2EarUVSgABSL wybE/V/5BVdcMsR36yYIIkR8ZpNwB/fXzzTamICPee28mAGMJGimkGJ+XEKZycvl7bRZPkoDYjAQj IJViktsVxkM2Hj4cfdS7+rkh+U1wspO9+fK8BLSzUE5lVbCi3tjWwt81xQ4y8ZyOoQG4tSyCvrjLd FGuhPGL0fnyTDL2MM1m/THE9OeEgMkQH4a7BQ1FQGonV7LQVuwzt88PoTlUPVAjdq/I4/xZDqkh78 wGQB2/av191a7VyudMllEA==; Date: Tue, 02 Sep 2025 18:02:39 +0300 Message-Id: <86qzwolwxc.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Tue, 02 Sep 2025 10:33:12 -0400) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Tue, 02 Sep 2025 10:33:12 -0400 > > Eli Zaretskii writes: > > > But make_process, called by server_accept_connection, already did > > this: > > > > pset_thread (p, Fcurrent_thread ()); > > > > So if we want to lock this new process to some other thread, we should > > fix that part as well to be consistent. > > True, that's a bug. > > > And why do you think this thread is a random one? If everything works > > as intended, it is the thread which created the existing process, > > because the descriptor whose presence in Available triggers the call > > to server_accept_connection is one of those on which pselect waited, > > and should have belonged to the current thread. > > Not if the existing process was unlocked. Then this is a random thread. Then let's fix the case of an unlocked process (which AFAIU is not what happened here). But if the process was locked to a particular thread, as that is the default, then do you agree that this code should be run by that very thread, at least nominally? > >> If that doesn't fix it (or you already had that commit), can you try > >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then > >> c93be71e45d4cebeb017c813426228e579e9381d and test again? > > > > What will that prove? Those changes are not going away, so trying > > that is just wasting everyone's time and energy. I thought we were > > past that... > > No, we're not past that, I still think those changes are wrong. > Especially because this bug report shows that those changes are indeed > breaking existing code. > > I repeatedly said that those changes would cause new issues to be > reported, and now it is happening. Maybe it doesn't convince you that > the changes need to be reverted, but you should at least be giving it a > little more credence now. This particular breakage is simply because my change was incomplete: it left some processes not locked to their thread, and the solution proposed by the OP, which fixed that blunder, is simpler and has fewer downsides than backing out the process locking to threads. This happens all the time in development, and the conclusion is rarely that the original changes should be backed out, certainly not if there are simpler fixes. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 15:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175682637318980 (code B ref 79367); Tue, 02 Sep 2025 15:20:01 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 15:19:33 +0000 Received: from localhost ([127.0.0.1]:35793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utSnE-0004w2-E2 for submit@debbugs.gnu.org; Tue, 02 Sep 2025 11:19:32 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60529) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utSn9-0004vk-Dz for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 11:19:28 -0400 From: Spencer Baugh In-Reply-To: <86qzwolwxc.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Sep 2025 18:02:39 +0300") References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> Date: Tue, 02 Sep 2025 11:19:21 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756826361; bh=fbjJS1RyxdctTeA4nrr6IFCwIJvKOZz/f7pX33w3GZ8=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=r41IxPOeeKZ4tU4k0SIzkBWMLDtDHqHyCOrXhXR3imPAhjewYrSuoHL79czaz3X58 xUcjhEHs0LTeIdou574DZdwu2i7YcLzfjuzqqpgEOC323U65y3Yh4bnXk8I/4Sjdzh EshKTd/M+9r2QX3Sd27ryqMYVVRIkgzmG1n65n5eVWkR0n50Qjw9LngMKbsDCOvL19 +PQCAKUS67gkeLuMY/jMip8oaQwKcHwIWgrgcT6iWI1NnMft6tBly0VmP2FeT0tOqi mIP8RMuNghFuknkVQygd4HUXyqymkIjQcKfKvGUKe3gnHihCXpi83hmU+LElcCvfUc BrL3SoEngsoAQ== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org >> Date: Tue, 02 Sep 2025 10:33:12 -0400 >> >> Eli Zaretskii writes: >> >> > But make_process, called by server_accept_connection, already did >> > this: >> > >> > pset_thread (p, Fcurrent_thread ()); >> > >> > So if we want to lock this new process to some other thread, we should >> > fix that part as well to be consistent. >> >> True, that's a bug. >> >> > And why do you think this thread is a random one? If everything works >> > as intended, it is the thread which created the existing process, >> > because the descriptor whose presence in Available triggers the call >> > to server_accept_connection is one of those on which pselect waited, >> > and should have belonged to the current thread. >> >> Not if the existing process was unlocked. Then this is a random thread. > > Then let's fix the case of an unlocked process (which AFAIU is not > what happened here). But if the process was locked to a particular > thread, as that is the default, then do you agree that this code > should be run by that very thread, at least nominally? Yes. But we can't rely on that since of course the process could be unlocked. Our code needs to behave correctly in both cases. >> >> If that doesn't fix it (or you already had that commit), can you try >> >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then >> >> c93be71e45d4cebeb017c813426228e579e9381d and test again? >> > >> > What will that prove? Those changes are not going away, so trying >> > that is just wasting everyone's time and energy. I thought we were >> > past that... >> >> No, we're not past that, I still think those changes are wrong. >> Especially because this bug report shows that those changes are indeed >> breaking existing code. >> >> I repeatedly said that those changes would cause new issues to be >> reported, and now it is happening. Maybe it doesn't convince you that >> the changes need to be reverted, but you should at least be giving it a >> little more credence now. > > This particular breakage is simply because my change was incomplete: > it left some processes not locked to their thread, and the solution > proposed by the OP, which fixed that blunder, is simpler and has fewer > downsides than backing out the process locking to threads. This > happens all the time in development, and the conclusion is rarely that > the original changes should be backed out, certainly not if there are > simpler fixes. That's true, but that doesn't change the fact that your change was broken and caused this bug. And I am annoyed that I have to debug issues caused by your own broken changes while you refuse the simple solution of backing out the broken change. Could we at least turn off your change by default, if we can't back it out? I would be happy to add code to do that. That will give us more time to iron out the issues with it. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 16:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175682962730835 (code B ref 79367); Tue, 02 Sep 2025 16:14:02 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 16:13:47 +0000 Received: from localhost ([127.0.0.1]:36171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utTdh-000817-Tn for submit@debbugs.gnu.org; Tue, 02 Sep 2025 12:13:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42624) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utTde-00080Z-5e for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 12:13:43 -0400 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 1utTdX-00046e-L7; Tue, 02 Sep 2025 12:13:35 -0400 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=dSZLzc66Xao7KxElhEciBVMNGLVmOkK9+wnW0v6y1K0=; b=sQSmhd6CF0kq hiffB9Pb0oiU3tfHMLAMRwBzW4SPZJSc47eQ4fnEA2yek8o+h+1EC/4+2LEaMVHC9HKhBQFz7ahrS YUwJ28REMlKwEzSCiLml0onida4HdJMG7B7OggVGZytAum+UfDIqF329i3CqPxGAHL+3ZQwRGDJow erRQsxupB8TNF/NtLGBnbSflYYeG/o22Z/PJOFKi7StO5a2Sl+Ewp6xloADII9Zqc74WSRlPWId5h K0vB6FMJrHN5/VYsbViya11fWBduMyv5M4EtqSdMe5P4W7kPKkbJmUcdMgdgUidFpeddbiT90BoAz Zh7qmg91pNmHkIDCg7YZSw==; Date: Tue, 02 Sep 2025 19:13:32 +0300 Message-Id: <86ldmwltn7.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Tue, 02 Sep 2025 11:19:21 -0400) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Tue, 02 Sep 2025 11:19:21 -0400 > > Eli Zaretskii writes: > > >> > And why do you think this thread is a random one? If everything works > >> > as intended, it is the thread which created the existing process, > >> > because the descriptor whose presence in Available triggers the call > >> > to server_accept_connection is one of those on which pselect waited, > >> > and should have belonged to the current thread. > >> > >> Not if the existing process was unlocked. Then this is a random thread. > > > > Then let's fix the case of an unlocked process (which AFAIU is not > > what happened here). But if the process was locked to a particular > > thread, as that is the default, then do you agree that this code > > should be run by that very thread, at least nominally? > > Yes. > > But we can't rely on that since of course the process could be unlocked. > Our code needs to behave correctly in both cases. If you mean the case where the original process was not locked to any thread, I agree: the fix should include both cases. It is easy to distinguish between a process that wasn't locked (in which case the new one shouldn't be locked, either), and the case where it was locked to a thread. If you mean something else, please elaborate. > > This particular breakage is simply because my change was incomplete: > > it left some processes not locked to their thread, and the solution > > proposed by the OP, which fixed that blunder, is simpler and has fewer > > downsides than backing out the process locking to threads. This > > happens all the time in development, and the conclusion is rarely that > > the original changes should be backed out, certainly not if there are > > simpler fixes. > > That's true, but that doesn't change the fact that your change was > broken and caused this bug. This happens all the time in development, to all of us. When it does, we install follow-up changes to fix the regressions. We don't usually revert the original ones, unless we learn that their ideas are unworkable, or cause much worse problems. This is not that case, not yet. > And I am annoyed that I have to debug issues caused by your own > broken changes while you refuse the simple solution of backing out > the broken change. It happens all the time in Emacs development that someone makes a mistake and someone else needs to debug and fix this. If you are annoyed in this case, just leave the debugging to me. Unlike some other people who make changes and disappear, I'm here, day in and day out, and when a bug due to my changes is reported, it is usually very high priority to me. (In this case, I responded within an hour of reading the bug report. Before you did, btw.) But backing out changes is not a "simple solution", because those changes were made for a reason. > Could we at least turn off your change by default, if we can't back it > out? I would be happy to add code to do that. That will give us more > time to iron out the issues with it. If we turn this off by default, then any problems, like this one, which need to be fixed as followup, will never materialize. So I must say no in this case. (I also don't think this strategy is correct in any software development in general.) If your use cases suffer from this, you can use set-process-thread to unlock your processes, as a stopgap. Although I would encourage you not to do that and report the problems instead, so that they could be debugged and fixed ASAP. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 16:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Spencer Baugh Cc: i@fuzy.me, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17568304991506 (code B ref 79367); Tue, 02 Sep 2025 16:29:01 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 16:28:19 +0000 Received: from localhost ([127.0.0.1]:36254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utTrm-0000OE-F8 for submit@debbugs.gnu.org; Tue, 02 Sep 2025 12:28:18 -0400 Received: from fhigh-b4-smtp.messagingengine.com ([202.12.124.155]:33449) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utTrj-0000Nx-Jg for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 12:28:16 -0400 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id B95257A035C; Tue, 2 Sep 2025 12:28:09 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Tue, 02 Sep 2025 12:28:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1756830489; x=1756916889; bh=AM6rYsZq7bdodL3fnRCEBD1aJXyM4d7GuLbbKNYLFlU=; b= OzW98nSWctnHfNf+kHuEbnPQJmRXtuV4KTGnE/qGbej+GZlRoJHTJPw95uvckItL /dAxU3f4SBZ5C4BYeEyKetyTAz4Kb035G6ZPd5VQr+vhsuYVLIOWIrlZmWGsCyB1 FF5etpG+Fc4pnNPR+t5/BH355V7bODQoKD8Uag8lXh8FXVtJmmX/QBbsThqm6WR/ SRWd7/BRPTnaSW4YBVyrVypY8KP4mS3Xq3eI4k9dVQ9lzT2m9rvkMTWH/gj1k5NN 7OITsbL1ezNpZeBQifnz05Ofk65WeNp1ZHNYKshqR6cIt6/7YtsaOJG1KNhRXYYt qSC4C6owZBvKe+xB0y/rCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756830489; x= 1756916889; bh=AM6rYsZq7bdodL3fnRCEBD1aJXyM4d7GuLbbKNYLFlU=; b=Q mBjOMmrIZeiu9uQ+ODS6jKIGS/OIJYgQLnYQiNhUblnG08UJhxE+Z3aXVvBrn1CS KXELXL2T+rept3w0fmegHUEuUXQNT94bife8mq3SUrfInT0bJIb9Jxz4EoQtFMMg 8ulRMP9NfffCLe+10TQLF21JRquYPlKuyFGGLivRLqBcoiG8Lc2vGFQOaAjhuVYp HiEAOfgqe6PirkwntpqLmXrC6oC+c9nbX9s8PohyIgl1pIhOR8VvR7xL+vcMBcGt 6wlq+dyGidW2pd761o8eGyiKWUnWwqFTPCxyp4lilSBacAjZpvLEzPWubjND46FB s7RiOeWygtZnCYziUQ1KQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegrihhl ohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpe fkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhihucfi uhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpe etudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhi esghhuthhovhdruggvvhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhht pdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshgsrghughhhse hjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopehisehfuhiihidrmhgvpdhrtghp thhtohepjeelfeeijeesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 2 Sep 2025 12:28:07 -0400 (EDT) Message-ID: <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> Date: Tue, 2 Sep 2025 19:28:05 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86qzwolwxc.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 02/09/2025 18:02, Eli Zaretskii wrote: >>>> If that doesn't fix it (or you already had that commit), can you try >>>> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then >>>> c93be71e45d4cebeb017c813426228e579e9381d and test again? >>> What will that prove? Those changes are not going away, so trying >>> that is just wasting everyone's time and energy. I thought we were >>> past that... >> No, we're not past that, I still think those changes are wrong. >> Especially because this bug report shows that those changes are indeed >> breaking existing code. >> >> I repeatedly said that those changes would cause new issues to be >> reported, and now it is happening. Maybe it doesn't convince you that >> the changes need to be reverted, but you should at least be giving it a >> little more credence now. > This particular breakage is simply because my change was incomplete: > it left some processes not locked to their thread, and the solution > proposed by the OP, which fixed that blunder, is simpler and has fewer > downsides than backing out the process locking to threads. This > happens all the time in development, and the conclusion is rarely that > the original changes should be backed out, certainly not if there are > simpler fixes. I do believe that when a change in a long-standing implementation causes an immediate issue we first consider reverting, especially when there is no consensus on the approach. A one-liner change is probably not a big deal by itself, but like Spencer said, the new process should at least follow the locking of its original thread, or something like this. And we still don't have a proposed fix on that. I don't want us to spend a lot of time arguing revert-or-no-revert now, but could you, Eli, try to decide on a full example of a buggy scenario which is really solved by thread locking being? Like, one that you consider a prime example. The present bug report doesn't count, since it's caused by an incomplete implementation. We'll need a specific piece of Lisp code, to be able to try different underlying implementations with it. So far I see two significant reasons to default to locking: - When we have scheduled some code to run on a different thread (filter/sentinel), there is no simple way to switch to a previous thread, to run it there. Unlike with the current buffer, for example. - Enabling locking later if a process starts without being locked to a thread, could be error-prone. But both only really work only if we understand specific problems being solved by locking in the first place. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 19:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17568407151329 (code B ref 79367); Tue, 02 Sep 2025 19:19:01 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 19:18:35 +0000 Received: from localhost ([127.0.0.1]:36669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utWWY-0000LN-Fb for submit@debbugs.gnu.org; Tue, 02 Sep 2025 15:18:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32862) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utWWV-0000L0-U7 for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 15:18:32 -0400 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 1utWWM-0002Ts-9w; Tue, 02 Sep 2025 15:18:25 -0400 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=e0K8wDtAQ8Nc2gKupltmOGBdVKYKvSzXphET6jM/zNQ=; b=NUE28I3IbG3+ wWCelo9lYyyhNAYMRl7Tos8Oie0EMHI3jSReusWg0A6HHGAvccuqmBBEU+sMF8TwUt6YmuF9P7py8 OqPk8a8+WodOLzP+L03ti9oFDOe02Jtx6+Xrs0byd00kiHRxzYHRHp/zPKbyMNvdCzxaDezLiof5h vtwLlEUesFgiLyu7JktuOTdKp3bd9zTddoQGFq7G884A4ZAhcRLcICNxy6EdhLt6X2apthLZoOoZp RguAqVlDyCgV98ZxRYPwh5CotSygcrQvywkuBXOxdSkFDf+LJDzfTcPYpG3Zhc/8RIE7XmOoigyqw eh8bLh+f4SFmnXlZ85Qlgw==; Date: Tue, 02 Sep 2025 22:18:20 +0300 Message-Id: <86cy88ll37.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> (message from Dmitry Gutov on Tue, 2 Sep 2025 19:28:05 +0300) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 2 Sep 2025 19:28:05 +0300 > Cc: i@fuzy.me, 79367@debbugs.gnu.org > From: Dmitry Gutov > > > This particular breakage is simply because my change was incomplete: > > it left some processes not locked to their thread, and the solution > > proposed by the OP, which fixed that blunder, is simpler and has fewer > > downsides than backing out the process locking to threads. This > > happens all the time in development, and the conclusion is rarely that > > the original changes should be backed out, certainly not if there are > > simpler fixes. > > I do believe that when a change in a long-standing implementation causes > an immediate issue we first consider reverting, especially when there is > no consensus on the approach. No, we don't. Reverting is actually the last resort, reserved for plain and clear mistakes, and for changes that cause grave regressions and cannot be fixed soon enough. > A one-liner change is probably not a big deal by itself, but like > Spencer said, the new process should at least follow the locking of its > original thread, or something like this. And we still don't have a > proposed fix on that. I can code the proposed fix in a few minutes, if there's agreement to what I proposed to do. I'm still uncertain what I proposed is agreed-upon. So let me reiterate that: . if the process on behalf of which we called server_accept_connection was not locked to some thread, undo what make_process did to the new process when it called pset_thread . otherwise, call set_proc_thread to lock the new process to the same thread as the one which caused this call > I don't want us to spend a lot of time arguing revert-or-no-revert now, > but could you, Eli, try to decide on a full example of a buggy scenario > which is really solved by thread locking being? I already described that in so many words. That is all I can afford. And please keep in mind that processes were being locked to threads since day one, just incompletely so. I didn't invent it just yesterday out of the blue: it's the original design of processes with threads. And if that is not good enough for you, then we will have to agree to disagree, and leave it at that. I stand by my opinion. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 19:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, Dmitry Gutov , 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17568416354318 (code B ref 79367); Tue, 02 Sep 2025 19:34:02 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 19:33:55 +0000 Received: from localhost ([127.0.0.1]:36692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utWlO-00017Z-Ra for submit@debbugs.gnu.org; Tue, 02 Sep 2025 15:33:55 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:33239) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utWlM-00017D-QJ for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 15:33:53 -0400 From: Spencer Baugh In-Reply-To: <86cy88ll37.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Sep 2025 22:18:20 +0300") References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> Date: Tue, 02 Sep 2025 15:33:46 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756841626; bh=JRzHPoLT4PdummGV531oC9k+7QsTxIto69rU4506O1U=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=NAAwL+mWfvNS28YKGhPGG+v+kMjaYLZAGNc6kProCvXu8eiFDkgQdm8imB0AxcKTx 9kdajzRHkEhKl9TBk80yjLjlK1cd5SdoZSuNTGLiOBcNwrW5nIUnHO3WAej6XmKg0d 5bdyE/lA0tea1Ap0R+sUauhSa+1Pw3SEMB/O9h38eWyZKUAXPoewN8S9B5YvDuHLcv qv4KH0baFzL9nlXVntDmjPpepNSkMzTO9V1r6mWNSEyTmHiGs+aRjfvIyQyNsz4Thk LZsfVYw66NYwl4ujX6nIRvy5SsOUyMXRwfL1bs430OWI/haXnjF2aw/fVVE8DcYKy4 amA922l8V8Lkw== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Date: Tue, 2 Sep 2025 19:28:05 +0300 >> Cc: i@fuzy.me, 79367@debbugs.gnu.org >> From: Dmitry Gutov >> >> > This particular breakage is simply because my change was incomplete: >> > it left some processes not locked to their thread, and the solution >> > proposed by the OP, which fixed that blunder, is simpler and has fewer >> > downsides than backing out the process locking to threads. This >> > happens all the time in development, and the conclusion is rarely that >> > the original changes should be backed out, certainly not if there are >> > simpler fixes. >> >> I do believe that when a change in a long-standing implementation causes >> an immediate issue we first consider reverting, especially when there is >> no consensus on the approach. > > No, we don't. Reverting is actually the last resort, reserved for > plain and clear mistakes, and for changes that cause grave regressions > and cannot be fixed soon enough. > >> A one-liner change is probably not a big deal by itself, but like >> Spencer said, the new process should at least follow the locking of its >> original thread, or something like this. And we still don't have a >> proposed fix on that. > > I can code the proposed fix in a few minutes, if there's agreement to > what I proposed to do. I'm still uncertain what I proposed is > agreed-upon. So let me reiterate that: > > . if the process on behalf of which we called > server_accept_connection was not locked to some thread, undo what > make_process did to the new process when it called pset_thread > . otherwise, call set_proc_thread to lock the new process to the > same thread as the one which caused this call Whatever you do, please post your change for review rather than just pushing it. >> I don't want us to spend a lot of time arguing revert-or-no-revert now, >> but could you, Eli, try to decide on a full example of a buggy scenario >> which is really solved by thread locking being? > > I already described that in so many words. Can you send that full description again? Perhaps I can translate it from words into code for you. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 19:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17568423686957 (code B ref 79367); Tue, 02 Sep 2025 19:47:01 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 19:46:08 +0000 Received: from localhost ([127.0.0.1]:36743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utWxE-0001o9-6K for submit@debbugs.gnu.org; Tue, 02 Sep 2025 15:46:08 -0400 Received: from fout-a5-smtp.messagingengine.com ([103.168.172.148]:33917) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utWxA-0001nK-IM for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 15:46:06 -0400 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id 07EC3EC05A6; Tue, 2 Sep 2025 15:45:58 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Tue, 02 Sep 2025 15:45:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1756842358; x=1756928758; bh=XKeT7xX+v2P7fX5QlGQeJIrypRtQRBV9P+xWIT4q89M=; b= CNk6FEMKYe5HcAUHdVDSIsZJmMpYFrY90SmvjWHhKkFMt4hedaslHcdFlMYsrHTM Mo2/rzHnEOQeabfIS0IEzPA6cvOgwlxbUa3JedNipHWsdqG5xl5qNi8LFUy3AFdQ zAvJbVuipcieDnzObFCbzdFB90e3epgNS0HkqK2WsOAW9DL3Cnt3gZ0TPMy39Q3J rFgrNLyTghKkCXbSFRtgJfvDgrreomDWa/FHHzi8QXwphOPf2Z7JXk83VUarPYmj wpf2zGzP/bS78frPzQmvwB/kWZ+en3fkBILz/85BFJFqYcuYB00GcXLc1AiygABw RBJ+Mf0pR9OVvcHebAt62A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756842358; x= 1756928758; bh=XKeT7xX+v2P7fX5QlGQeJIrypRtQRBV9P+xWIT4q89M=; b=Q GZb8kgn4acr3J+BDL+xfe6d4wty2szznt+hogpzDBbZTR4VmhpzJEfPC1MWle6gF PmD4oP++zBf1TKNiC42qB0wEv5/RGs89zcLlyav85dSyY61Rx/pAa/WRx6DuX+Gs T1pmTX3sSunz/7WPmCd00kqdtujKFqX9jmUPaemmt5nY5NsXoRJRQudIr2fwOFuN 0/u8FhjL7DnumZAnDfIPIWCkEDUeV4gBXOE41x4bbnLUTNh2TBjZLQBnSmVtHF2G 9ki8UXIQdghtHfiVlzTfxdgoHSQoU5aO5oRQXXx8lFVjP2Djy4pEcllfZttBXMZx IsSkAOlFt/8EWrvEdDeXA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh epteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeehnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrh ihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehssggruhhghh esjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghpthhtohepihesfhhuiiihrdhmvgdprhgt phhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 2 Sep 2025 15:45:56 -0400 (EDT) Message-ID: <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@gutov.dev> Date: Tue, 2 Sep 2025 22:45:54 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86cy88ll37.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 02/09/2025 22:18, Eli Zaretskii wrote: >> I do believe that when a change in a long-standing implementation causes >> an immediate issue we first consider reverting, especially when there is >> no consensus on the approach. > > No, we don't. Reverting is actually the last resort, reserved for > plain and clear mistakes, and for changes that cause grave regressions > and cannot be fixed soon enough. A "mistake" is often in the eyes of the beholder. The lack of consensus is something more objective. >> A one-liner change is probably not a big deal by itself, but like >> Spencer said, the new process should at least follow the locking of its >> original thread, or something like this. And we still don't have a >> proposed fix on that. > > I can code the proposed fix in a few minutes, if there's agreement to > what I proposed to do. I'm still uncertain what I proposed is > agreed-upon. So let me reiterate that: > > . if the process on behalf of which we called > server_accept_connection was not locked to some thread, undo what > make_process did to the new process when it called pset_thread > . otherwise, call set_proc_thread to lock the new process to the > same thread as the one which caused this call Sounds about right. >> I don't want us to spend a lot of time arguing revert-or-no-revert now, >> but could you, Eli, try to decide on a full example of a buggy scenario >> which is really solved by thread locking being? > > I already described that in so many words. That is all I can afford. We need a fuller scenario. If not with code, then a full use case described in English. I'm pretty sure more of your time is being wasted on answering the emails with objections. Regrettably. > And please keep in mind that processes were being locked to threads > since day one, just incompletely so. I didn't invent it just > yesterday out of the blue: it's the original design of processes with > threads. IIUC the existing protection did very little in practice, all of these years: it only stopped some thread calling 'accept-process-output' with an explicit reference of a process belonging to another thread. Any kind of buggy code would have to try hard to obtain that reference in the first place - so that would almost never happen anyway. The new protections seem a lot more strict. TBC I think we should continue to support locking, and your current fix seems productive in this regard, but whether locking should be by default is not obvious to me - and at least two smart devs who worked with Emacs Lisp threads say no. That seems like grounds to re-evaluate. Even if we reach the current default we'll have documented our conclusions better rather than just saying "this is so". From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Sep 2025 21:22:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175684808924235 (code B ref 79367); Tue, 02 Sep 2025 21:22:06 +0000 Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 21:21:29 +0000 Received: from localhost ([127.0.0.1]:36978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utYRQ-0006ID-OL for submit@debbugs.gnu.org; Tue, 02 Sep 2025 17:21:28 -0400 Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:60157) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utYRK-0006GB-0I for 79367@debbugs.gnu.org; Tue, 02 Sep 2025 17:21:21 -0400 Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 7429914001AA; Tue, 2 Sep 2025 17:21:12 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Tue, 02 Sep 2025 17:21:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1756848072; x=1756934472; bh=OBOBMaMvP0o6eGthMVOXGtXrI+2rV3KN301xapYXi+U=; b= sgAnLPfGjl7VEexbo3xk+BFVzAjPwYgjjjjJ/yBazP+dWfY5Wv0z9H2Q0Wy/bcgt uvuRiaWEEp6qpy6gDTlclX71AsoFAJG79JxqaaKHhw+wvKcLVWJa7VR601TloZCV UxtTr2s5QhUzJP7D/eKPNjs36LFs1T21SfvGvVhNDO2xgNjOm2omuIhq/tIV40Qd ju4bBVRaTkyitfbjp9K03FJovCco5C2mlaKxwFXl4aaGB7DjD7vRsuuL7kA4nLfm +hOYP39j0JhmeLiLwELYwH8mYgDzs27WqGtqPBApG+FduXDYUM8uAHQIKpIuMfXp 2yUtT0ukV9IGqEf/KM7Pbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756848072; x= 1756934472; bh=OBOBMaMvP0o6eGthMVOXGtXrI+2rV3KN301xapYXi+U=; b=l 6JbM+r+LkHv7j6qM6X2L9WV75nJ+uTFGW4orLBaGSlY1JFh3yOqjZtvNV19hzQIp rtxWT5isv/ndo4MBeC3IIRQnv6eqSTUay/WBOA3jXkH7Hs0+wLV2epGnuY+6DI/z xFvIja+PN5xV4lLMatAu0kucYl1v+XXayCZFgSSbXsdafPPiwdH/r+9uhjWMDsAf 5+iKwV5e+7n8CPxCSATcJUH8d1h2r2BoB0A2gKPqFcGqaz3t/SKnSb+fTkeOLwPu 6beXiAXkPCmVghx2lg6Ec0erzyEgij5GCXgs0g95I6bio+rbWOvFf2VTNUQgq2IX p4eiqxB4BVB1HAUebAXRQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffhvfevfhgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh epkeefudefgfejffefvdfhteegveevhfekkeekhffgudfhveejteffhfegueetgefgnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrh ihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehisehfuhiihi drmhgvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgt phhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 2 Sep 2025 17:21:10 -0400 (EDT) Message-ID: <217ebef0-4b97-47a3-8118-ed1e8c176852@gutov.dev> Date: Wed, 3 Sep 2025 00:21:09 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Dmitry Gutov References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@gutov.dev> Content-Language: en-US In-Reply-To: <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@gutov.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 02/09/2025 22:45, Dmitry Gutov wrote: > We need a fuller scenario. If not with code, then a full use case > described in English. Maybe to start something, do we expect some Comint functionality to be broken when background threads exist and perhaps call 'accept-process-output' with nil, in a loop? Such as comint-redirect-results-list-from-process or comint-proc-query, for example. Or among third party code, inf-ruby-completions. All of these call 'accept-process-output' with their own process object. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 11:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17568987924394 (code B ref 79367); Wed, 03 Sep 2025 11:27:02 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 11:26:32 +0000 Received: from localhost ([127.0.0.1]:39018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utldI-00018o-CW for submit@debbugs.gnu.org; Wed, 03 Sep 2025 07:26:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44440) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utldF-00018a-9q for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 07:26:30 -0400 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 1utld7-0005eC-D7; Wed, 03 Sep 2025 07:26:21 -0400 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=2Awzy4dOtTuhIiZZ0dZ7fxMw/8dzW18h0lszy+NGizw=; b=h4uaJz1uARJN SKvT2d5pt/ulwPNNjFGxLYg65oJmE8OXIWbVfqSLUP9MJHErVwURVUivivdiZsLyS4FZK/bWdvfEL LLU9l23rNfHIc+WXocByx0khOwW5EtaACxdZzd8daXRZBUrtEoo+w+yGmqBZFdd0pvg2gMYyAaYi7 FZ77MXIUTVtaESK9NdTJGZ5wqye1DhMgy5h03W0ZIxahgDoA+5hmAS0MOSCogwFmFwN8RiwlFKtOM WICroLtFSVCj5/Z/ap3eMlHeFd3X8iWXjmYd/MSICwokRYvu/h+/TBYT/xiZziMmsqFc7riBGZhpY KJkYPD7Hp/RSQ3SjQZu0dw==; Date: Wed, 03 Sep 2025 14:25:58 +0300 Message-Id: <86a53blqux.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Tue, 02 Sep 2025 15:33:46 -0400) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Dmitry Gutov , i@fuzy.me, 79367@debbugs.gnu.org > Date: Tue, 02 Sep 2025 15:33:46 -0400 > > Eli Zaretskii writes: > > > I can code the proposed fix in a few minutes, if there's agreement to > > what I proposed to do. I'm still uncertain what I proposed is > > agreed-upon. So let me reiterate that: > > > > . if the process on behalf of which we called > > server_accept_connection was not locked to some thread, undo what > > make_process did to the new process when it called pset_thread > > . otherwise, call set_proc_thread to lock the new process to the > > same thread as the one which caused this call > > Whatever you do, please post your change for review rather than just > pushing it. Will do. > >> I don't want us to spend a lot of time arguing revert-or-no-revert now, > >> but could you, Eli, try to decide on a full example of a buggy scenario > >> which is really solved by thread locking being? > > > > I already described that in so many words. > > Can you send that full description again? Perhaps I can translate it > from words into code for you. Look at my posts as part of discussing bug#79201. For example: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#88 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#94 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#100 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#106 From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 11:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175690047919724 (code B ref 79367); Wed, 03 Sep 2025 11:55:02 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 11:54:39 +0000 Received: from localhost ([127.0.0.1]:39049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utm4U-000583-MT for submit@debbugs.gnu.org; Wed, 03 Sep 2025 07:54:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42286) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utm4S-00057o-3k for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 07:54:36 -0400 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 1utm4K-0002mJ-Gs; Wed, 03 Sep 2025 07:54:28 -0400 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=XwbGwOBkkYLoW5m3FW5jyfac16KJjpQIaZpjJynxoMI=; b=VGMER8AEc7tY QeAaLpDDgBu8JRzebU88JRW5cvtUEFVt8zUxPYzhPmRO0Ex80xjll8E8LXYUs54j628+7C5VlYlYc H/+quaSf4xJucS9rBvxL99LO84UQEaghGdjxaAXmSs6RgJ3COoKfz61qNsNcza6lHRaImpd6+MYMf 37vPn+pbb66V3yYM8uCGfoamZ9nDl3I5iGy2ls9x2Dye4++Jqswiri6ND5haIQnkAMJGbUoD52LCr 8i+9jpxW345sG6YGQQGXb+ekgoOHdnspOwBpbzucDL4QBZ2QtuJbaxuR/HNbuUmvNpg0Ct1nKLcYG /sxTHLKeoSsDgYVl2+qslA==; Date: Wed, 03 Sep 2025 14:53:42 +0300 Message-Id: <868qivlpkp.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@gutov.dev> (message from Dmitry Gutov on Tue, 2 Sep 2025 22:45:54 +0300) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@gutov.dev> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 2 Sep 2025 22:45:54 +0300 > Cc: sbaugh@janestreet.com, i@fuzy.me, 79367@debbugs.gnu.org > From: Dmitry Gutov > > On 02/09/2025 22:18, Eli Zaretskii wrote: > > >> I do believe that when a change in a long-standing implementation causes > >> an immediate issue we first consider reverting, especially when there is > >> no consensus on the approach. > > > > No, we don't. Reverting is actually the last resort, reserved for > > plain and clear mistakes, and for changes that cause grave regressions > > and cannot be fixed soon enough. > > A "mistake" is often in the eyes of the beholder. The lack of consensus > is something more objective. I said "clear mistakes". Those aren't in the eyes of the beholder, they are clear to everyone. > > . if the process on behalf of which we called > > server_accept_connection was not locked to some thread, undo what > > make_process did to the new process when it called pset_thread > > . otherwise, call set_proc_thread to lock the new process to the > > same thread as the one which caused this call > > Sounds about right. Thanks, will do. > >> I don't want us to spend a lot of time arguing revert-or-no-revert now, > >> but could you, Eli, try to decide on a full example of a buggy scenario > >> which is really solved by thread locking being? > > > > I already described that in so many words. That is all I can afford. > > We need a fuller scenario. If not with code, then a full use case > described in English. I described some of them, and just now posted a list of my messages in bug#79201 where I did that. That's the best I can afford doing at this time, sorry. > I'm pretty sure more of your time is being wasted on answering the > emails with objections. Regrettably. Yes. And I still consider this a worthwhile investment, if as result we will become on the same page regarding how the relevant code works and what should be our expectations from it. > > And please keep in mind that processes were being locked to threads > > since day one, just incompletely so. I didn't invent it just > > yesterday out of the blue: it's the original design of processes with > > threads. > > IIUC the existing protection did very little in practice, all of these > years: it only stopped some thread calling 'accept-process-output' with > an explicit reference of a process belonging to another thread. That's not "very little" at all. And if some Lisp program called set-process-thread, it would do exactly what is now done by default. > Any kind > of buggy code would have to try hard to obtain that reference in the > first place - so that would almost never happen anyway. The new > protections seem a lot more strict. Yes, it is stricter. Because that's the intent, as is clear both from the code and from the documentation, and also because it makes Lisp programs much easier to reason about. I also don't quite see a disaster this change is causing to code which disregarded the documented restriction. All we had till now is a single bug report, which clearly indicates that my change was incomplete, and is easy to fix. I fail to understand the amount of excitement due to a change that turns out not to be different from many other changes we make in development. Here's one recent example: https://lists.gnu.org/archive/html/emacs-devel/2025-09/msg00002.html This even broke the build, which is clearly a serious regression. And the solution was that Mattias quickly installed two followup changes; case closed. Good job, Mattias! > TBC I think we should continue to support locking, and your current fix > seems productive in this regard, but whether locking should be by > default is not obvious to me - and at least two smart devs who worked > with Emacs Lisp threads say no. That seems like grounds to re-evaluate. > Even if we reach the current default we'll have documented our > conclusions better rather than just saying "this is so". I'm not saying we cannot revisit the decision to lock processes to threads. But given that the original design and implementation clearly tell us that was the intent, I think we should start from what we have, and only change it if we decide that the current default is wrong in too many important cases. For now all we have is 2 cases: one was solved yesterday by unlocking the process, the other is the one discussed here, which uncovered a flaw in the change I installed, and should be easy to fix. That's not enough to declare the idea of locking wrong as the default, let alone bankrupt. For such a far-reaching conclusion we need much more data points, of both kinds. My knowledge of this code and my experience, based on 12 years of developing, maintaining, and fixing bugs in it, is that letting random threads read output from subprocesses causes many unexpected behaviors and thus triggers subtle bugs and non-determinism in seemingly valid Lisp programs. You think differently, but please don't dismiss my opinions on this too quickly, given my familiarity with the code in this area and the amount of time I spent on it. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 11:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175690064620396 (code B ref 79367); Wed, 03 Sep 2025 11:58:02 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 11:57:26 +0000 Received: from localhost ([127.0.0.1]:39065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utm7C-0005Iu-7K for submit@debbugs.gnu.org; Wed, 03 Sep 2025 07:57:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47098) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utm78-0005Ic-Ij for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 07:57:23 -0400 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 1utm72-0003JE-ED; Wed, 03 Sep 2025 07:57:16 -0400 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=q8mgufMl0pBxTX8FJmqbVs3qaXSpSwhjlQhC1ezVEyU=; b=Pe80oKie3+QT MtQSrXlsMGBxDQjh/rPREjYaP1JnIPlCnl1NBRuKxjJTWrCAQ8I9VrS2ZXWfffdVUvCo+Dzu25qzh jjIT/0m9waCF9YcAtJAHxfqxqBboI2J4nwpiHYxXJOQoxEEZlBcMLGvz2hBv7GXLdemaqJ7UyGZ3s hxgui5JgMdqovuR03tRW15X1isooWAj7A+mpWc1I/G+B/yL9piqP0DsNpPwtWZmy0uRALoDuN9jGF UaRpbmNDtva6d20NvTDOYWYB81KHiegs9PpG5Ore25A1sRoKNnLbAQadIZiSX9owM8/1h4cqEufdI N719zH/CpRmzXffTYDtwSA==; Date: Wed, 03 Sep 2025 14:57:13 +0300 Message-Id: <867byflpeu.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <217ebef0-4b97-47a3-8118-ed1e8c176852@gutov.dev> (message from Dmitry Gutov on Wed, 3 Sep 2025 00:21:09 +0300) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@gutov.dev> <217ebef0-4b97-47a3-8118-ed1e8c176852@gutov.dev> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 3 Sep 2025 00:21:09 +0300 > From: Dmitry Gutov > Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org > > On 02/09/2025 22:45, Dmitry Gutov wrote: > > We need a fuller scenario. If not with code, then a full use case > > described in English. > > Maybe to start something, do we expect some Comint functionality to be > broken when background threads exist and perhaps call > 'accept-process-output' with nil, in a loop? > > Such as comint-redirect-results-list-from-process or comint-proc-query, > for example. If the process is locked to the thread which runs comint-redirect-results-list-from-process, I wouldn't expect problems there. But it would be good for someone to look into this, sure. > Or among third party code, inf-ruby-completions. All of these call > 'accept-process-output' with their own process object. Same, I think. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 12:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175690187623977 (code B ref 79367); Wed, 03 Sep 2025 12:18:01 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 12:17:56 +0000 Received: from localhost ([127.0.0.1]:39107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utmR1-0006Ee-FU for submit@debbugs.gnu.org; Wed, 03 Sep 2025 08:17:55 -0400 Received: from fhigh-b1-smtp.messagingengine.com ([202.12.124.152]:59259) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utmQy-0006EQ-7d for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 08:17:53 -0400 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id B26AD7A02C5; Wed, 3 Sep 2025 08:17:46 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Wed, 03 Sep 2025 08:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1756901866; x=1756988266; bh=R5p8T0p+6+iKgeDMN/TImPDQupo6JJk61Xu420K2M44=; b= LUAQ3iBvlHRSzdE2nuBWeADMvA3wSEvY8j60zklDu+s3CX3GXEoeAGOUFO+PwD9Y dUPnBzL9qM/s5meNqepeqzbZ7JAJ6t8auRpq0eR1umHcHc1LYT4AYxfYLRmdUB9A LqYrzSy9SQjSvhquLE5ynFkMVnWvnHv9iDudVYcrUuggDM+LWzov2VmKokJnZBIX ELmoCnhblPYFICuIRGPY0h4TbLbhEcYv80dMA6ERLgQmVpTlWJUlqu75OGxDt4i7 dlAi9r4YkBuDoXyly9HgLwV4kx0g4nl1svHBPXFukpTKoURgjecxZ1AWNhB//+AH T6ZgDo4W77OAMxadcM277A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756901866; x= 1756988266; bh=R5p8T0p+6+iKgeDMN/TImPDQupo6JJk61Xu420K2M44=; b=G WpEOYuXwoK7CzMlif9FjIwQ92r4cle98rm+JmSeQaIQCALbzXLN2mMtOH57hVljk P5HxKi2fUYNbgbnKPKelQOQQNdo/nzcs26gmJfASJ8LoVgrcHlMIgbITITmlbVGR 6gSeaJ4Ggh4wTqY4e5ZXlIBmCkULdPQ/MujH5K1CV4VUSnc1VRdsyR0cpk1cl2LB 514Xv1vvQIj4K9xG6J3VKgvBGvWZoYcaWROyYQt3Q4laQHqQPaga8Kt5tQl6gnHg SpI+9jMSYPrfTR1ZKjmOSzTIITdVBoJqsWj/7qPx7wFnNbHMYJSzDIXBXv2V3RGg AFhOAEGWXShTgtI4mIv2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdefuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh epteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeehnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrh ihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehisehfuhiihi drmhgvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgt phhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Sep 2025 08:17:44 -0400 (EDT) Message-ID: Date: Wed, 3 Sep 2025 15:17:42 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@gutov.dev> <217ebef0-4b97-47a3-8118-ed1e8c176852@gutov.dev> <867byflpeu.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <867byflpeu.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 03/09/2025 14:57, Eli Zaretskii wrote: >> Maybe to start something, do we expect some Comint functionality to be >> broken when background threads exist and perhaps call >> 'accept-process-output' with nil, in a loop? >> >> Such as comint-redirect-results-list-from-process or comint-proc-query, >> for example. > If the process is locked to the thread which runs > comint-redirect-results-list-from-process, I wouldn't expect problems > there. But it would be good for someone to look into this, sure. Right, I meant the unlocked configuration (this could be an evidence of it being bad default). From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 13:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17569053593611 (code B ref 79367); Wed, 03 Sep 2025 13:16:02 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 13:15:59 +0000 Received: from localhost ([127.0.0.1]:39375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utnLC-0000wB-RD for submit@debbugs.gnu.org; Wed, 03 Sep 2025 09:15:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46892) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utnL8-0000vp-FW for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 09:15:57 -0400 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 1utnL1-0003oA-GE; Wed, 03 Sep 2025 09:15:48 -0400 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=1RJVuPTwhBm5r2ArNrqK3jDHMsME0Oc/rVxaT/9+Dcs=; b=hg8/jC3wyBhu mGHcEq+YlEi7udHt7BN0shbG2dr8E8/TOtlQ0gxNJmYkpxw5zGmqOjaWK0tLqvH4EPVQFwkON4mYU sIBbZwP+r5Wum8A7gzv64LfcHHcljlFYshuOul4lbZigQb9hiifQti2TsQ819wM9qxphNAwoT2zw5 39nf8fAMDTUer01JgkJyBu567af04oJp0/S2g9cf0v8niNLzMiHhKvYODznyvGKDTfI2waq2btxqw 08NWlo4komXJ73+lZ1F80p74p/XjnzKN1ZyL8UeTg4LEcLYVYqHPUQYEPGrWa0QVnI2lcSttcwTay pFaH+cPDxAXToqjYjiqUng==; Date: Wed, 03 Sep 2025 16:15:42 +0300 Message-Id: <86v7lzk77l.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Dmitry Gutov on Wed, 3 Sep 2025 15:17:42 +0300) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@gutov.dev> <217ebef0-4b97-47a3-8118-ed1e8c176852@gutov.dev> <867byflpeu.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 3 Sep 2025 15:17:42 +0300 > Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org > From: Dmitry Gutov > > On 03/09/2025 14:57, Eli Zaretskii wrote: > >> Maybe to start something, do we expect some Comint functionality to be > >> broken when background threads exist and perhaps call > >> 'accept-process-output' with nil, in a loop? > >> > >> Such as comint-redirect-results-list-from-process or comint-proc-query, > >> for example. > > If the process is locked to the thread which runs > > comint-redirect-results-list-from-process, I wouldn't expect problems > > there. But it would be good for someone to look into this, sure. > > Right, I meant the unlocked configuration (this could be an evidence of > it being bad default). I'm not familiar with the expectations of this function. Is it expected to wait in a loop until PROCESS exits, and process the output only then? If yes, the only question is what happens when PROCESS exits while another thread has the global lock. This is related to a problem discussed in bug#79334, so maybe we should revisit this when that bug is deemed solved. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 14:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: sbaugh@janestreet.com, i@fuzy.me, dmitry@gutov.dev Cc: 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175690883816248 (code B ref 79367); Wed, 03 Sep 2025 14:14:02 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 14:13:58 +0000 Received: from localhost ([127.0.0.1]:40691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utoFJ-0004E0-V8 for submit@debbugs.gnu.org; Wed, 03 Sep 2025 10:13:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39110) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utoFE-0004De-PC for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 10:13:55 -0400 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 1utoF7-00023J-Rw; Wed, 03 Sep 2025 10:13:45 -0400 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=z4RQinoFGwTUfFAsx9g76euurO30UhRSOZtcSvIp/CM=; b=UW4VltxmV4KB DsUyeHaZWn3/APzHYThGkTZsz+vJnnk2NBKVtaBFANO2aPDu6HqPwD5d9yLT6uGvZeWC3VHXO81Xj 9uiqHxzx3HH0MfNkLQLXuuh50DqgJwFlARGZOoDaOv6NZWEeghRUvhfHMO+VXzS8XVeZ4P6x3m37A hZYbLGBKwNd9QI0kIIxl7PISSnLXNmJvmntDH9FrxFtLZV1lstWlibpujjEXfBfjlSHrzi3snldQy zBy/ICnLJD/T35BWqpgkDJnZhBxI+vbJWJNgoVsQbgDgka0k5vShxr3PSAP4o/bC1Q9wyTly95Tcg 8OqLMwzTSpxrh53JKBmwTQ==; Date: Wed, 03 Sep 2025 17:13:42 +0300 Message-Id: <86seh3k4ix.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86a53blqux.fsf@gnu.org> (message from Eli Zaretskii on Wed, 03 Sep 2025 14:25:58 +0300) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Wed, 03 Sep 2025 14:25:58 +0300 > From: Eli Zaretskii > > > > . if the process on behalf of which we called > > > server_accept_connection was not locked to some thread, undo what > > > make_process did to the new process when it called pset_thread > > > . otherwise, call set_proc_thread to lock the new process to the > > > same thread as the one which caused this call > > > > Whatever you do, please post your change for review rather than just > > pushing it. > > Will do. The proposed patch is below. Zhengyi Fu, can you please apply it to the current master, and see if it solves the original problem? diff --git a/src/process.c b/src/process.c index d6efac5..0c41ec6 100644 --- a/src/process.c +++ b/src/process.c @@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel) fcntl (s, F_SETFL, O_NONBLOCK); p = XPROCESS (proc); + /* make_process calls pset_thread, but if the server process is not + locked to any thread, we need to undo what make_process did. */ + if (NILP (ps->thread)) + pset_thread (p, Qnil); /* Build new contact information for this setup. */ contact = Fcopy_sequence (ps->childp); @@ -5117,6 +5121,13 @@ server_accept_connection (Lisp_Object server, int channel) add_process_read_fd (s); if (s > max_desc) max_desc = s; + /* If the server process is locked to this thread, lock the client + process to the same thread. */ + if (!NILP (ps->thread)) + { + eassert (XTHREAD (ps->thread) == current_thread); + set_proc_thread (p, XTHREAD (ps->thread)); + } /* Setup coding system for new process based on server process. This seems to be the proper thing to do, as the coding system From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 14:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175691056321538 (code B ref 79367); Wed, 03 Sep 2025 14:43:02 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 14:42:43 +0000 Received: from localhost ([127.0.0.1]:40753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utoh7-0005bJ-Pv for submit@debbugs.gnu.org; Wed, 03 Sep 2025 10:42:42 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:60649) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utoh3-0005ax-OO for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 10:42:39 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 40D9A43A1E; Wed, 3 Sep 2025 14:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1756910551; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=08dzd6TZlzQoQj4/FUqZXUKSsjnuCu4A/fsKlm/WM6g=; b=QdpB+DaI/cMt9IA61eeE7KuoC4BxzLRaTIVjWboWHvq2DygcevZJPaVfgW7ZN8Rt7vkVxb 30jqPgruikLiKQDxz4WFoPO0nwg72ZrKvbEqyOFqeEcYNxfUK0y8rCPBadJO2wtFW1nmOZ so82VaS4MMcRWWtZpc8r0iXx+yP4FTgPT/rAMqviJPrdzjPS4HWjxinSO+b4L3tfPJEy95 ObWMKKTCR7jLBWKdZDqkHHh+ra+/wnOfzV1RwyeN2G08ka2V/bU6i9sT88ftyurk/og3oA zJ31TF493v3UJL4NSKLKiSBuONpMsK5JltaZUuHC1hjDwYW4SF8hzE+6HLMrzQ== From: Zhengyi Fu In-Reply-To: <86seh3k4ix.fsf@gnu.org> References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> Date: Wed, 03 Sep 2025 22:42:26 +0800 Message-ID: <87ecsny4vh.fsf@fuzy.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdefgeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfgfgggtsehttdertddtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeetvdeuveffjedugfdtjeeugfejjeegtdekteefffdtgefgffetffeiuefhtdegfeenucfkphepgeehrdekrddukeeirddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgeehrdekrddukeeirddutddvpdhhvghloheptggrlhhlihhophgvpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepgedprhgtphhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepughmihhtrhihsehguhhtohhvrdguvghvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org >> Date: Wed, 03 Sep 2025 14:25:58 +0300 >> From: Eli Zaretskii >> >> > > . if the process on behalf of which we called >> > > server_accept_connection was not locked to some thread, undo what >> > > make_process did to the new process when it called pset_thread >> > > . otherwise, call set_proc_thread to lock the new process to the >> > > same thread as the one which caused this call >> > >> > Whatever you do, please post your change for review rather than just >> > pushing it. >> >> Will do. > > The proposed patch is below. > > Zhengyi Fu, can you please apply it to the current master, and see if > it solves the original problem? It does resolve my original problem. But I think we need to call set_proc_thread when the server process is not locked as well. Otherwise the `thread' member of the fd_callback_info may still be a dangling pointer. > diff --git a/src/process.c b/src/process.c > index d6efac5..0c41ec6 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel) > fcntl (s, F_SETFL, O_NONBLOCK); > > p = XPROCESS (proc); > + /* make_process calls pset_thread, but if the server process is not > + locked to any thread, we need to undo what make_process did. */ > + if (NILP (ps->thread)) > + pset_thread (p, Qnil); > > /* Build new contact information for this setup. */ > contact = Fcopy_sequence (ps->childp); > @@ -5117,6 +5121,13 @@ server_accept_connection (Lisp_Object server, int channel) > add_process_read_fd (s); > if (s > max_desc) > max_desc = s; > + /* If the server process is locked to this thread, lock the client > + process to the same thread. */ > + if (!NILP (ps->thread)) > + { > + eassert (XTHREAD (ps->thread) == current_thread); > + set_proc_thread (p, XTHREAD (ps->thread)); > + } > > /* Setup coding system for new process based on server process. > This seems to be the proper thing to do, as the coding system From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 14:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Zhengyi Fu Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175691121023784 (code B ref 79367); Wed, 03 Sep 2025 14:54:01 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 14:53:30 +0000 Received: from localhost ([127.0.0.1]:40839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utora-0006BY-1A for submit@debbugs.gnu.org; Wed, 03 Sep 2025 10:53:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47968) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utorX-0006BK-Dm for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 10:53:28 -0400 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 1utorQ-00086a-Vh; Wed, 03 Sep 2025 10:53:20 -0400 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=MrISA5Q9ScbgQmxntFvRJyCRIiUmXAcY6QkOgkhhs+w=; b=pjljptO3Mqg3 lQTUO9y9I4xGwIC4CpcO1g5XbOQ39kgik2mzHZNuRTHjqnghPu631cYoUz/urSakd5JbZX80bXaEC cuj0mpvcKOEE/JNG0D68Ia0bNcl6R9bbj2f5p2gE0Pz8WlABktE9fy+rdSdjbGR7hmGzd6OavEics BZWs2mTgNgQxaQbM/Mco2Y2YR0yOig7UWRytC8/TWdl7/hJVo4AU9+aApBBxxjR450ljIJBWtIlXF 8Cv0msPwnuSac0HI3gifDZSSYuDZzh1JOu9qGxcqWnMW1LQ5acwTLgeW1lpBxCtTNHGClnCWi64ds Wr83uTyvkLPuR5LnZ14fdw==; Date: Wed, 03 Sep 2025 17:53:17 +0300 Message-Id: <86plc7k2oy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87ecsny4vh.fsf@fuzy.me> (message from Zhengyi Fu on Wed, 03 Sep 2025 22:42:26 +0800) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zhengyi Fu > Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Wed, 03 Sep 2025 22:42:26 +0800 > > Eli Zaretskii writes: > > > Zhengyi Fu, can you please apply it to the current master, and see if > > it solves the original problem? > > It does resolve my original problem. Thanks for testing. > But I think we need to call set_proc_thread when the server process > is not locked as well. Otherwise the `thread' member of the > fd_callback_info may still be a dangling pointer. Oh, you mean the below? I agree, it is safer. diff --git a/src/process.c b/src/process.c index d6efac5..2cfff61 100644 --- a/src/process.c +++ b/src/process.c @@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel) fcntl (s, F_SETFL, O_NONBLOCK); p = XPROCESS (proc); + /* make_process calls pset_thread, but if the server process is not + locked to any thread, we need to undo what make_process did. */ + if (NILP (ps->thread)) + pset_thread (p, Qnil); /* Build new contact information for this setup. */ contact = Fcopy_sequence (ps->childp); @@ -5117,6 +5121,16 @@ server_accept_connection (Lisp_Object server, int channel) add_process_read_fd (s); if (s > max_desc) max_desc = s; + /* If the server process is locked to this thread, lock the client + process to the same thread, otherwise clear the thread of its I/O + descriptors. */ + if (NILP (ps->thread)) + set_proc_thread (p, NULL); + else + { + eassert (XTHREAD (ps->thread) == current_thread); + set_proc_thread (p, XTHREAD (ps->thread)); + } /* Setup coding system for new process based on server process. This seems to be the proper thing to do, as the coding system From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 14:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175691148524733 (code B ref 79367); Wed, 03 Sep 2025 14:59:01 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 14:58:05 +0000 Received: from localhost ([127.0.0.1]:40861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utow1-0006Qr-0K for submit@debbugs.gnu.org; Wed, 03 Sep 2025 10:58:05 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:48439) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utovy-0006Q7-Ap for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 10:58:03 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 8E7671F737; Wed, 3 Sep 2025 14:57:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1756911475; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uC+LbQZQFwyudstsiipzsokRDrgyRrN4/UlNyVB8yCw=; b=Z6NVVPck2HUDzsOWxtknM1/Wgs/MjTQ7oMAYbkPoWzbZ3Ug+5+xdLWHsAU1OdNI4msFBbo rAhxUkofbTU5NmBJ2irLdwqcMiZT6F9viDH1BvshoiUjEAR/yabMia2wPp+77ZdW6lTWBt 5YF3pO/lNf1n/94/RaDIFDQYyKxYElEottrGeJeqWINf/oxDRfj86cymVp3S7QJtQL3EDL OzDREKPWwRaOxNZt/3uA8Rx7VUv28dFiRw733Csnd3dU48roU1fP1YnDBlmXQWMCQCYaqM +OCfKibytZqXZfJhylalndgEtLFTe+6z5PFZxjBdJfbQz//Lb+W1YnIibNOX2Q== From: Zhengyi Fu In-Reply-To: <86plc7k2oy.fsf@gnu.org> References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> Date: Wed, 03 Sep 2025 22:57:50 +0800 Message-ID: <877byfy45t.fsf@fuzy.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdefgeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfgfgggtsehttdertddtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeetvdeuveffjedugfdtjeeugfejjeegtdekteefffdtgefgffetffeiuefhtdegfeenucfkphepgeehrdekrddukeeirddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgeehrdekrddukeeirddutddvpdhhvghloheptggrlhhlihhophgvpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepgedprhgtphhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepughmihhtrhihsehguhhtohhvrdguvghvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Zhengyi Fu >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org >> Date: Wed, 03 Sep 2025 22:42:26 +0800 >> >> Eli Zaretskii writes: >> >> > Zhengyi Fu, can you please apply it to the current master, and see if >> > it solves the original problem? >> >> It does resolve my original problem. > > Thanks for testing. > >> But I think we need to call set_proc_thread when the server process >> is not locked as well. Otherwise the `thread' member of the >> fd_callback_info may still be a dangling pointer. > > Oh, you mean the below? I agree, it is safer. > > diff --git a/src/process.c b/src/process.c > index d6efac5..2cfff61 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel) > fcntl (s, F_SETFL, O_NONBLOCK); > > p = XPROCESS (proc); > + /* make_process calls pset_thread, but if the server process is not > + locked to any thread, we need to undo what make_process did. */ > + if (NILP (ps->thread)) > + pset_thread (p, Qnil); > > /* Build new contact information for this setup. */ > contact = Fcopy_sequence (ps->childp); > @@ -5117,6 +5121,16 @@ server_accept_connection (Lisp_Object server, int channel) > add_process_read_fd (s); > if (s > max_desc) > max_desc = s; > + /* If the server process is locked to this thread, lock the client > + process to the same thread, otherwise clear the thread of its I/O > + descriptors. */ > + if (NILP (ps->thread)) > + set_proc_thread (p, NULL); > + else > + { > + eassert (XTHREAD (ps->thread) == current_thread); > + set_proc_thread (p, XTHREAD (ps->thread)); > + } > > /* Setup coding system for new process based on server process. > This seems to be the proper thing to do, as the coding system Yes. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 15:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Zhengyi Fu , 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175691162825508 (code B ref 79367); Wed, 03 Sep 2025 15:01:02 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 15:00:28 +0000 Received: from localhost ([127.0.0.1]:40870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utoyJ-0006dM-US for submit@debbugs.gnu.org; Wed, 03 Sep 2025 11:00:28 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:47967) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utoyH-0006cx-5Z for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 11:00:25 -0400 From: Spencer Baugh In-Reply-To: <86plc7k2oy.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Sep 2025 17:53:17 +0300") References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> Date: Wed, 03 Sep 2025 11:00:19 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756911619; bh=jJIGO7fPF+KAZUlIKyCLwQ19WvI2m1HaLdTPSMH0sEM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=XlYveYEPFIdFDA9TB9Zx5OelwqEljEA+2rpBklAq2y9ygzQJoJs3fGJRF4R2lNOFg MFkcTnehri0AnjxkbPMak7V+kC+YV0WqoaXsPS1C1wr0IEKKFIJ/FgzdGId9zxhDKu gNnEDQHH6XhQoULD4jDJ5im/V4J1ne/DSD0l7XIr6u4bWJo+/pPNOJ7yoBt9uXkISH 7CQPb1kx4xzYA85LExnMq9eM/r5R04jF9tWR/iGr2I9okHC0bUdYAg3qS5dS4aQet1 QGBkR61DtUp0rMEn/T/PeU5wPKYpr1pCaPNGdAsjeYT414U2TEvA0G0EYhr3q904Xa 1Ewx350tTbJ/A== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Zhengyi Fu >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org >> Date: Wed, 03 Sep 2025 22:42:26 +0800 >> >> Eli Zaretskii writes: >> >> > Zhengyi Fu, can you please apply it to the current master, and see if >> > it solves the original problem? >> >> It does resolve my original problem. > > Thanks for testing. > >> But I think we need to call set_proc_thread when the server process >> is not locked as well. Otherwise the `thread' member of the >> fd_callback_info may still be a dangling pointer. > > Oh, you mean the below? I agree, it is safer. We should not do that - if the thread member of fd_callback_info is a dangling pointer, that indicates there's a bug elsewhere. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 15:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175691283230085 (code B ref 79367); Wed, 03 Sep 2025 15:21:01 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 15:20:32 +0000 Received: from localhost ([127.0.0.1]:41002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utpHj-0007p9-Kv for submit@debbugs.gnu.org; Wed, 03 Sep 2025 11:20:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57318) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utpHg-0007oo-Dq for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 11:20:29 -0400 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 1utpHY-0003Oc-Q7; Wed, 03 Sep 2025 11:20:20 -0400 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=+hdFGGGzeJZMAxLwmCEksVNho1UyC5W7MDHNDk8w8VA=; b=UlCnV0N7nBto uXs5/6tYwNp6IPqIXWFZ/Tb46U5Ob+27BcT+LC3jvBtskrV/akjGZ0n8O15oVyiPK0jwMyAEDh8D+ wxE1rDCNa2SB5hwWWkiodwgBMYXINJlcLPYTWsEcx2YFzoJacFgE0PfZy0hpX5gfavkThi05DxwzV RXs/Mjd/8QqNPSIHU/3xjQcESPtweFhIWz9BG2H5xd67UMviPU0S6npoPuZ+PRLOBrU8m0/snnQd6 YXJ4/Ra9Y+xlcEc3e1FAAQmVxen512clChToCDIOfXFp2llUBkhkupvetYIEYqzs3xr27g/q8mxOK YiYTvLL+MWpQSMTVW6C+Hg==; Date: Wed, 03 Sep 2025 18:20:17 +0300 Message-Id: <86o6rrk1fy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 03 Sep 2025 11:00:19 -0400) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Zhengyi Fu , 79367@debbugs.gnu.org, dmitry@gutov.dev > Date: Wed, 03 Sep 2025 11:00:19 -0400 > > Eli Zaretskii writes: > > >> From: Zhengyi Fu > >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > >> Date: Wed, 03 Sep 2025 22:42:26 +0800 > >> > >> Eli Zaretskii writes: > >> > >> > Zhengyi Fu, can you please apply it to the current master, and see if > >> > it solves the original problem? > >> > >> It does resolve my original problem. > > > > Thanks for testing. > > > >> But I think we need to call set_proc_thread when the server process > >> is not locked as well. Otherwise the `thread' member of the > >> fd_callback_info may still be a dangling pointer. > > > > Oh, you mean the below? I agree, it is safer. > > We should not do that - if the thread member of fd_callback_info is a > dangling pointer, that indicates there's a bug elsewhere. So how about adding an assertion before we clear it? From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 16:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17569154326665 (code B ref 79367); Wed, 03 Sep 2025 16:04:01 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 16:03:52 +0000 Received: from localhost ([127.0.0.1]:41168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utpxf-0001jQ-Uw for submit@debbugs.gnu.org; Wed, 03 Sep 2025 12:03:52 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:39477) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utpxc-0001j8-Ja for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 12:03:50 -0400 From: Spencer Baugh In-Reply-To: <86o6rrk1fy.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Sep 2025 18:20:17 +0300") References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> Date: Wed, 03 Sep 2025 12:03:42 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756915422; bh=WL8717ylL4aoUyBzOClfaaiASKxjJygvc1iuiNdBDhI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=MfL+T+YWpXeL+aIDAiyoPPF80jJRqon3DhmVqaNt4eYQm1zOroa1cKtXXliXG0Ii6 rS1xHBO0O5oeHH38aLYxHEsTT9XkdqTHKMeXKcwmOyGnyhQYLGRiiEHQv8FkCrFe8s h6fTtVu1nzWGEGxliwIRQ7alGyIygGs6il4kXSUWw92aGxiC55/pmOE2YfdlPtGr1h cr0yuiaDZquntUGo69nsocHkw4wekVh/pLVkMcIjN0RbZQ1rarJnuobeZnjnz4+Xog BN3LSeBkiZomCefP9WY5kUXsyulFuMnJSP16hkCpbjC11gTuHL9uKSZiDsaW9Dsl4I Fe1btlgd1h+gA== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: Zhengyi Fu , 79367@debbugs.gnu.org, dmitry@gutov.dev >> Date: Wed, 03 Sep 2025 11:00:19 -0400 >> >> Eli Zaretskii writes: >> >> >> From: Zhengyi Fu >> >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org >> >> Date: Wed, 03 Sep 2025 22:42:26 +0800 >> >> >> >> Eli Zaretskii writes: >> >> >> >> > Zhengyi Fu, can you please apply it to the current master, and see if >> >> > it solves the original problem? >> >> >> >> It does resolve my original problem. >> > >> > Thanks for testing. >> > >> >> But I think we need to call set_proc_thread when the server process >> >> is not locked as well. Otherwise the `thread' member of the >> >> fd_callback_info may still be a dangling pointer. >> > >> > Oh, you mean the below? I agree, it is safer. >> >> We should not do that - if the thread member of fd_callback_info is a >> dangling pointer, that indicates there's a bug elsewhere. > > So how about adding an assertion before we clear it? Sure. fd_callback_info.thread specifically should always be NULL at the time we're using the fd_callback_info slot for some new fd, so we should assert that. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 16:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175691780313965 (code B ref 79367); Wed, 03 Sep 2025 16:44:02 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 16:43:23 +0000 Received: from localhost ([127.0.0.1]:41266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utqZu-0003dB-Jl for submit@debbugs.gnu.org; Wed, 03 Sep 2025 12:43:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52186) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utqZr-0003cp-HH for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 12:43:20 -0400 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 1utqZl-0003Vb-4D; Wed, 03 Sep 2025 12:43:13 -0400 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=CpwLG0ZNoIHPZ6EmpoVmQxFIBBomggEp23dfvCbN0+I=; b=sYXb9dKQfDai blz79hS8AX/Ua1KQUcKhpawoDVc3zsq+sQC/2QRDlIgawYg6ifELv4bMCYQmRGAnYlRe/nAKCSLwE xhHOdNBx5kYcVzYy1PQ/geiX+rZ0/7F2zGqrWnAdMspKYze0ENMUpZEP3iEoao9R8e7YVBRQ6Ssr1 8acqp+OPp1KAYkmZVW3wup5I6WqYfikkpkKGHb0Fxcwd+3yza7Tpx3mpj9s5uzMhE8VCmUwN9LwAD WzguVa0RRf5swLkMmxRYxnW538X8V0hhN38sI8ftnaf28QFAb5aQUsbs407Dcx1QNYa3E/4IwSOpb YujWvNOVEm3cAgASThI5Rg==; Date: Wed, 03 Sep 2025 19:42:47 +0300 Message-Id: <86ldmvjxmg.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 03 Sep 2025 12:03:42 -0400) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev > Date: Wed, 03 Sep 2025 12:03:42 -0400 > > Eli Zaretskii writes: > > >> >> But I think we need to call set_proc_thread when the server process > >> >> is not locked as well. Otherwise the `thread' member of the > >> >> fd_callback_info may still be a dangling pointer. > >> > > >> > Oh, you mean the below? I agree, it is safer. > >> > >> We should not do that - if the thread member of fd_callback_info is a > >> dangling pointer, that indicates there's a bug elsewhere. > > > > So how about adding an assertion before we clear it? > > Sure. fd_callback_info.thread specifically should always be NULL at the > time we're using the fd_callback_info slot for some new fd, so we should > assert that. So, this: diff --git a/src/process.c b/src/process.c index d6efac5..8f5be5e 100644 --- a/src/process.c +++ b/src/process.c @@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel) fcntl (s, F_SETFL, O_NONBLOCK); p = XPROCESS (proc); + /* make_process calls pset_thread, but if the server process is not + locked to any thread, we need to undo what make_process did. */ + if (NILP (ps->thread)) + pset_thread (p, Qnil); /* Build new contact information for this setup. */ contact = Fcopy_sequence (ps->childp); @@ -5117,6 +5121,19 @@ server_accept_connection (Lisp_Object server, int channel) add_process_read_fd (s); if (s > max_desc) max_desc = s; + /* If the server process is locked to this thread, lock the client + process to the same thread, otherwise clear the thread of its I/O + descriptors. */ + if (NILP (ps->thread)) + { + eassert (!fd_callback_info[p->infd].thread); + set_proc_thread (p, NULL); + } + else + { + eassert (XTHREAD (ps->thread) == current_thread); + set_proc_thread (p, XTHREAD (ps->thread)); + } /* Setup coding system for new process based on server process. This seems to be the proper thing to do, as the coding system From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 17:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175691923719432 (code B ref 79367); Wed, 03 Sep 2025 17:08:02 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 17:07:17 +0000 Received: from localhost ([127.0.0.1]:41392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utqx3-00053L-2w for submit@debbugs.gnu.org; Wed, 03 Sep 2025 13:07:17 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:33903) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utqwz-00052d-Dv for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 13:07:14 -0400 From: Spencer Baugh In-Reply-To: <86ldmvjxmg.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Sep 2025 19:42:47 +0300") References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> Date: Wed, 03 Sep 2025 13:07:08 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756919228; bh=DqQrHCBuKkeQ/J/i1Ln383EBPE/pg5jc62Ix657DHOk=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=uWTG0WUPICvFs9bFbuaKfk+mYmJvs8YEpImGxEsA3FIZt+sKG7e1AEp8K+QF7Lrpt HiSZrkb0WCuZ8ef2y8n9I6FA1DU4rNakGxNt4161BCtAMgIyTIzqmeqy2aUVqqqFmm C/qCXUuSbRbT0APR5QHpCOzx9XroCWzWkzN0B49+BaE/7dNjd9rpuiPLobQqLomXtA JvCowQUr6+bDm2NoE4TJbFWS4qvk0DRHbsXkWtlEX9DhUHUOUeYV7PanJUOnSePLv0 flcD1rRnG1zBhMc6onc8aSMhcU18xuWUa/tbN+gWooQ0C7G6or/qo/y540GdgdzCp8 JHznpFpiu/pTw== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev >> Date: Wed, 03 Sep 2025 12:03:42 -0400 >> >> Eli Zaretskii writes: >> >> >> >> But I think we need to call set_proc_thread when the server process >> >> >> is not locked as well. Otherwise the `thread' member of the >> >> >> fd_callback_info may still be a dangling pointer. >> >> > >> >> > Oh, you mean the below? I agree, it is safer. >> >> >> >> We should not do that - if the thread member of fd_callback_info is a >> >> dangling pointer, that indicates there's a bug elsewhere. >> > >> > So how about adding an assertion before we clear it? >> >> Sure. fd_callback_info.thread specifically should always be NULL at the >> time we're using the fd_callback_info slot for some new fd, so we should >> assert that. > > So, this: > > diff --git a/src/process.c b/src/process.c > index d6efac5..8f5be5e 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel) > fcntl (s, F_SETFL, O_NONBLOCK); > > p = XPROCESS (proc); > + /* make_process calls pset_thread, but if the server process is not > + locked to any thread, we need to undo what make_process did. */ > + if (NILP (ps->thread)) > + pset_thread (p, Qnil); We should probably just unconditionally do: pset_thread (p, ps->thread) here. > /* Build new contact information for this setup. */ > contact = Fcopy_sequence (ps->childp); > @@ -5117,6 +5121,19 @@ server_accept_connection (Lisp_Object server, int channel) > add_process_read_fd (s); > if (s > max_desc) > max_desc = s; > + /* If the server process is locked to this thread, lock the client > + process to the same thread, otherwise clear the thread of its I/O > + descriptors. */ > + if (NILP (ps->thread)) > + { > + eassert (!fd_callback_info[p->infd].thread); > + set_proc_thread (p, NULL); Yes, this is the right assertion. But it should be outside the if/else because it's true even if ps->thread isn't nil. This whole if/else conditional should probably be just: eassert (!fd_callback_info[p->infd].thread); if (!NILP (p->thread)) { eassert (XTHREAD (ps->thread) == current_thread); set_proc_thread (p, XTHREAD (p->thread)); } It's not necessary to call set_proc_thread(p, NULL) in the other case since it will just set .thread to NULL, which we're already asserting anyway. > + } > + else > + { > + eassert (XTHREAD (ps->thread) == current_thread); > + set_proc_thread (p, XTHREAD (ps->thread)); > + } From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Sep 2025 18:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17569226917041 (code B ref 79367); Wed, 03 Sep 2025 18:05:01 +0000 Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 18:04:51 +0000 Received: from localhost ([127.0.0.1]:41879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utrql-0001pU-2z for submit@debbugs.gnu.org; Wed, 03 Sep 2025 14:04:51 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:57129) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utrqi-0001pG-Fg for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 14:04:49 -0400 From: Spencer Baugh In-Reply-To: <86a53blqux.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Sep 2025 14:25:58 +0300") References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> Date: Wed, 03 Sep 2025 14:04:42 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756922682; bh=AfwoCdfK0HeKIOIqJfe7ciUvcXHHWB86uRuSyhdodXA=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=OxC4bVdiLsaY2tc97wBmiXiBDf65yYim13q56KKBzwZ33J7Rna14SbiSj2nW1hbmD bxljMkus6GJMTs2jgTpAkxXg9EMB1x3WjMRdjDJyWGJiEgW4XClzKSysQM1fM86v34 hkuF/E7tHf4UBYPqUsGbyqW+AgbWE2Qs+HSSNsCZdsw5WjM4qF92m1wJzgwG93vbgm ZrKX2AFc0bT8gMlSAVg3EX0DNckJ7nbyLzPou6Q8JwOczvY/avRdVorrXodBHJe4wJ CLviRnw8Btr5g2sFrzDXNsj+Rps3mHfw/wX/V7a0XqLIIcaw60AP5ZNifrPA6TfDv6 ILSUmMNfpvyxA== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: Dmitry Gutov , i@fuzy.me, 79367@debbugs.gnu.org >> Date: Tue, 02 Sep 2025 15:33:46 -0400 >> >> Eli Zaretskii writes: >> >> > I can code the proposed fix in a few minutes, if there's agreement to >> > what I proposed to do. I'm still uncertain what I proposed is >> > agreed-upon. So let me reiterate that: >> > >> > . if the process on behalf of which we called >> > server_accept_connection was not locked to some thread, undo what >> > make_process did to the new process when it called pset_thread >> > . otherwise, call set_proc_thread to lock the new process to the >> > same thread as the one which caused this call >> >> Whatever you do, please post your change for review rather than just >> pushing it. > > Will do. > >> >> I don't want us to spend a lot of time arguing revert-or-no-revert now, >> >> but could you, Eli, try to decide on a full example of a buggy scenario >> >> which is really solved by thread locking being? >> > >> > I already described that in so many words. >> >> Can you send that full description again? Perhaps I can translate it >> from words into code for you. > > Look at my posts as part of discussing bug#79201. For example: OK, attempting to excerpt the parts where you describe what could go wrong when a thread is unlocked: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#88 > Wouldn't we want the thread to be able to read the output > from its process after the wait? Without marking the descriptors with > the thread, that output could have been read by some other thread > during the wait, and then our thread will hang forever if it calls > accept-process-output after the wait ended -- a much more serious > problem, and in a program that has no bug per se. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#94 > > > An output from a process could have been read by a thread other than > > > the one that started the process, thus "starving" the thread that > > > started the process from reading its output. > > > > That has been possible, and common, since threads were originally added. > > And caused strange bugs, whereby a thread that started a process would > hang in accept-process-output because some other thread inadvertently > read the output from that process. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#100 > If you study the code in wait_reading_process_output, you will > immediately see what kind of godawful mess will that cause with > reading output from several processes started by several threads. > > wait_reading_process_output was written under an implicit assumption > that there's only one thread that handles all the subprocesses. > Therefore, it consistently checks all of the I/O descriptors for > available input from the subprocesses, and consumes that as soon as > it's available. That cannot possibly work reliably, let alone > predictably, when several threads are involved. This is so obvious > from reading the code that I'm astonished I need to even explain it. Note that we need to make sure wait_reading_process_output works reliably in this case for the sake of processes which aren't locked to threads. So defaulting to locking processes to threads doesn't actually help with this. > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#106 > Moreover, IME many weird problems and buggy behavior in Lisp programs > using threads were caused by the wrong thread inadvertently reading > output of a process, which then left the thread that waits for that > process's output stuck waiting forever. If anything, we should make > process locking to its thread stronger, not weaker, if we want > relatively simple threaded programs to work reliably. So, to summarize, it sounds like your issue with not locking processes to threads is: Without locking processes to the creating thread, a process's output can be read by some other thread during the wait, and then our thread will hang forever if it calls accept-process-output after the wait ended. This is unfortunately not detailed enough to translate into code. I've never seen a real-world program which would be vulnerable to this problem, as described here. I can make up toy programs which meet this description which would hang, but I'm not sure they're actually what you're concerned about. Especially because they aren't anything like real-world programs. Could you give some more details about the scenario, so I can try to write a test demonstrating the problem? Or could you point to a real-world program which is vulnerable to this problem, so I can turn it into a test? From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2025 01:34:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175694962921410 (code B ref 79367); Thu, 04 Sep 2025 01:34:03 +0000 Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 01:33:49 +0000 Received: from localhost ([127.0.0.1]:44015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utyrE-0005ZF-CW for submit@debbugs.gnu.org; Wed, 03 Sep 2025 21:33:49 -0400 Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]:59933) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utyr7-0005Yw-Lr for 79367@debbugs.gnu.org; Wed, 03 Sep 2025 21:33:44 -0400 Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfout.stl.internal (Postfix) with ESMTP id 44BAD1D00221; Wed, 3 Sep 2025 21:33:35 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Wed, 03 Sep 2025 21:33:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1756949615; x=1757036015; bh=C6HLUHnPs1egmfCaQZRYj/fc9hwzCA0i1LcjUSrhA0g=; b= d4TBAtVKZy4x1fkXCRwq80B7BbJU20oxmuwx7hnbphnbefY433kNv5zz+U8rDKmP Bo/s180kF32QT4dZxkxQ8vaSgflGZsw2ni8tnMJhQ46Sv0iVsFsmJijIW534MnxO OrSg9i/VfCnFydmeE/GVfYI44qQIZwBJkS0AaKz92+BNhoVcANAvbeCATiP31T88 rBkM3Seu95jRSWgCPfXFPuumfCCYvyz1tkowAL1wdRFaJeFCICt3cPnH6nXcPtAL 4/GTpB5gqa324dIpZFljLCe9ZQrFNh+ITi/ot1GFsv+RubNsUi3M8HaA9aJXTdIW GVw/6O7QT7ky/7FL3omlwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756949615; x= 1757036015; bh=C6HLUHnPs1egmfCaQZRYj/fc9hwzCA0i1LcjUSrhA0g=; b=O 5eTk43uZju6MtWH45HQCOLpMYG6TOsDpgTdTtpLxOfcjFzBtYgaXQZ6dfVhC2qiC 0IRAdOK24BKd3vM6I7cMiHe/Jpsbv5OEU+3vecVNd8kPZuXiPzdy3UCFs7vbb7b6 TdOdV0sLte4h18JRKwc2y//1uoduQW7IB9k84Onjc+B099aRhLwa+X0N82w/7GDj YlBM0lhiR5+enzJ55FABgQHJqHJQvleBJmkkc1lXkjAAg3duj49uLc69lTYI6G6j jce/rOmikYFTU7+LuzEkSfj8MusTQQdyC+PwhiS6tzPRoaJNn08FNg/GO2M5ofyN h+IlGc08N4AcOdxsNm4qA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdegjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh epffeifedvleeukedtgfelieegudfgveekfeejveejffetffeuueeugefhveeiuddvnecu ffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghp thhtohepihesfhhuiiihrdhmvgdprhgtphhtthhopeejleefieejseguvggssghughhsrd hgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Sep 2025 21:33:33 -0400 (EDT) Message-ID: <6eb705bd-7481-4e77-9f76-b0815d373c5a@gutov.dev> Date: Thu, 4 Sep 2025 04:33:31 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@gutov.dev> <868qivlpkp.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <868qivlpkp.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 03/09/2025 14:53, Eli Zaretskii wrote: >>>> I don't want us to spend a lot of time arguing revert-or-no-revert now, >>>> but could you, Eli, try to decide on a full example of a buggy scenario >>>> which is really solved by thread locking being? >>> >>> I already described that in so many words. That is all I can afford. >> >> We need a fuller scenario. If not with code, then a full use case >> described in English. > > I described some of them, and just now posted a list of my messages in > bug#79201 where I did that. That's the best I can afford doing at > this time, sorry. Thanks. Will follow the subthread that sprung from this paragraph. >> I'm pretty sure more of your time is being wasted on answering the >> emails with objections. Regrettably. > > Yes. And I still consider this a worthwhile investment, if as result > we will become on the same page regarding how the relevant code works > and what should be our expectations from it. I hope to get there as well. >> IIUC the existing protection did very little in practice, all of these >> years: it only stopped some thread calling 'accept-process-output' with >> an explicit reference of a process belonging to another thread. > > That's not "very little" at all. And if some Lisp program called > set-process-thread, it would do exactly what is now done by default. Right. But we don't know of any that did. >> Any kind >> of buggy code would have to try hard to obtain that reference in the >> first place - so that would almost never happen anyway. The new >> protections seem a lot more strict. > > Yes, it is stricter. Because that's the intent, as is clear both from > the code and from the documentation, and also because it makes Lisp > programs much easier to reason about. > > I also don't quite see a disaster this change is causing to code which > disregarded the documented restriction. All we had till now is a > single bug report, which clearly indicates that my change was > incomplete, and is easy to fix. I fail to understand the amount of > excitement due to a change that turns out not to be different from > many other changes we make in development. Spencer also previously mentioned breakage in some existing code, there was an example in another thread (not about native compilation). > Here's one recent example: > > https://lists.gnu.org/archive/html/emacs-devel/2025-09/msg00002.html > > This even broke the build, which is clearly a serious regression. And > the solution was that Mattias quickly installed two followup changes; > case closed. Good job, Mattias! I'm good with fixing this bug report the expedient way. >> TBC I think we should continue to support locking, and your current fix >> seems productive in this regard, but whether locking should be by >> default is not obvious to me - and at least two smart devs who worked >> with Emacs Lisp threads say no. That seems like grounds to re-evaluate. >> Even if we reach the current default we'll have documented our >> conclusions better rather than just saying "this is so". > > I'm not saying we cannot revisit the decision to lock processes to > threads. But given that the original design and implementation > clearly tell us that was the intent, I think we should start from what > we have, and only change it if we decide that the current default is > wrong in too many important cases. For now all we have is 2 cases: > one was solved yesterday by unlocking the process, the other is the > one discussed here, which uncovered a flaw in the change I installed, > and should be easy to fix. That's not enough to declare the idea of > locking wrong as the default, let alone bankrupt. Certainly. > For such a > far-reaching conclusion we need much more data points, of both kinds. > My knowledge of this code and my experience, based on 12 years of > developing, maintaining, and fixing bugs in it, is that letting random > threads read output from subprocesses causes many unexpected behaviors > and thus triggers subtle bugs and non-determinism in seemingly valid > Lisp programs. I have an inkling that even in the single-threaded case accept-process-output can behave unpredictably enough that people use it in a certain way (in a loop, with low timeout). Which could smooth over unpredictabilities across multiple threads as well. There are some exceptions to that, though. > You think differently, but please don't dismiss my > opinions on this too quickly, given my familiarity with the code in > this area and the amount of time I spent on it. Just to be clear, I haven't formed an opinion on this myself yet. Just hoping for a more thorough discussion. Sorry if it comes across differently. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2025 04:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17569612993381 (code B ref 79367); Thu, 04 Sep 2025 04:49:02 +0000 Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 04:48:19 +0000 Received: from localhost ([127.0.0.1]:44456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uu1tS-0000sR-Re for submit@debbugs.gnu.org; Thu, 04 Sep 2025 00:48:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44550) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uu1tP-0000s7-Tl for 79367@debbugs.gnu.org; Thu, 04 Sep 2025 00:48:17 -0400 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 1uu1tI-0003OX-Dg; Thu, 04 Sep 2025 00:48:09 -0400 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=d8rhIzvu+c2km9wahldEnf1eYCWVlpsa0VL7nmYJNKQ=; b=dobGe5bJ6WcX yyQYPqWwO/v4iBZll89N7h+V1akUCXy8zUocL2TP0NqLqWmqpDn0knLR9AmAO/fxYtaqiktrX6ILz M9evvKJ65M+qh9No3q+rSd8+OoB4crrcfWkXyj62TN+pMT9JOcyyBuSMwoRUi/nSg4ruWHkqw5cXd uJTi3TIg6OTsMRaHW1Qb4aC1hkBmCsr6I7tP8nGTG1a1Sgk0TS+AZvJmbZoaRME0EzBCPxYROGcPh rruSLPQS0rQAny/FjU4hCtD6TN6w1ApT2uvx1M5XbSBXcYV6yzlmwrObRynMxEPkU+miZj9KBq8GB n2gSomEZ/LPDBeWnK/x1rQ==; Date: Thu, 04 Sep 2025 07:48:05 +0300 Message-Id: <86ikhykem2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 03 Sep 2025 13:07:08 -0400) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev > Date: Wed, 03 Sep 2025 13:07:08 -0400 > > Eli Zaretskii writes: > > > + /* make_process calls pset_thread, but if the server process is not > > + locked to any thread, we need to undo what make_process did. */ > > + if (NILP (ps->thread)) > > + pset_thread (p, Qnil); > > We should probably just unconditionally do: > pset_thread (p, ps->thread) > here. That's a bit dangerous, since the I/O descriptors of the new process are not yet set, so the call to pset_thread there, in case ps->thread is non-nil, would do a partial job. We could instead move the pset_thread call to later, where set_proc_thread is called, but I preferred to undo what make_process did ASAP. > > > /* Build new contact information for this setup. */ > > contact = Fcopy_sequence (ps->childp); > > @@ -5117,6 +5121,19 @@ server_accept_connection (Lisp_Object server, int channel) > > add_process_read_fd (s); > > if (s > max_desc) > > max_desc = s; > > + /* If the server process is locked to this thread, lock the client > > + process to the same thread, otherwise clear the thread of its I/O > > + descriptors. */ > > + if (NILP (ps->thread)) > > + { > > + eassert (!fd_callback_info[p->infd].thread); > > + set_proc_thread (p, NULL); > > Yes, this is the right assertion. But it should be outside the if/else > because it's true even if ps->thread isn't nil. I don't mind moving it out. > This whole if/else conditional should probably be just: > > eassert (!fd_callback_info[p->infd].thread); > if (!NILP (p->thread)) > { > eassert (XTHREAD (ps->thread) == current_thread); > set_proc_thread (p, XTHREAD (p->thread)); > } > > It's not necessary to call set_proc_thread(p, NULL) in the other case > since it will just set .thread to NULL, which we're already asserting > anyway. The assertions compile to nothing in a production build. Also, I don't like the caller to assume too much about what set_proc_thread does, it's not future-proof. So I'd prefer to leave that call in place. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2025 05:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17569631469839 (code B ref 79367); Thu, 04 Sep 2025 05:20:02 +0000 Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 05:19:06 +0000 Received: from localhost ([127.0.0.1]:44517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uu2NG-0002Yd-3L for submit@debbugs.gnu.org; Thu, 04 Sep 2025 01:19:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56002) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uu2ND-0002Y7-H6 for 79367@debbugs.gnu.org; Thu, 04 Sep 2025 01:19:04 -0400 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 1uu2N6-0008PU-ME; Thu, 04 Sep 2025 01:18:56 -0400 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=ykJYTfbKRn5xgg3C2HcoHarEk0lqv0wBElDyGxogdfI=; b=XmToRYpOpaRq pwuewjQf+W/bxfpECzDczvJrvjhSbYZ+a2s0wIzpIrPmfjYrJhMvPyVwbETvXSxh7hPlSyWJIYazF Pk8TlWw+3wkYDz0Oy5BoO7mvX9sE97oRcj3+0RQ0uNCq+FapI90btLw9FaeADsOrOjjcrR+/kBnLt 6yRQOaM1uCLmZHMh4DF/zLxAvr5tyTaqQcEqFp5E+mh/L+JAI7va9ayEKmNGl58l5hj922mvo/k5U uSQvxTtx86N0dS7t7L4Z9hYwmU6AyUslUNwgkseQ644vXvD9baMRMJGkCUBQWC5dN3/eNUly1rwhV YRBuTpdGPbYlQglQ2MwhLQ==; Date: Thu, 04 Sep 2025 08:18:54 +0300 Message-Id: <86ecsmkd6p.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 03 Sep 2025 14:04:42 -0400) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: i@fuzy.me, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Wed, 03 Sep 2025 14:04:42 -0400 > > Eli Zaretskii writes: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#100 > > > If you study the code in wait_reading_process_output, you will > > immediately see what kind of godawful mess will that cause with > > reading output from several processes started by several threads. > > > > wait_reading_process_output was written under an implicit assumption > > that there's only one thread that handles all the subprocesses. > > Therefore, it consistently checks all of the I/O descriptors for > > available input from the subprocesses, and consumes that as soon as > > it's available. That cannot possibly work reliably, let alone > > predictably, when several threads are involved. This is so obvious > > from reading the code that I'm astonished I need to even explain it. > > Note that we need to make sure wait_reading_process_output works > reliably in this case for the sake of processes which aren't locked to > threads. So defaulting to locking processes to threads doesn't actually > help with this. Not if we consider unlocked processes a rare and unusual thing to do, in which case programmers that use this are responsible for the dealing with the results. We made such a change in comp.el, but I cannot say I'm too happy with it, and hope we will revisit that later and find a better solution. We do need to make sure nothing disastrous happens in that case, like crashes or EBADF or Emacs hung and unresponsive, but that's just a small part of "works reliably", and is not my primary concern here. My primary concern is that the results of letting processes be unlocked will cause many unexpected and randomly-unpredictable results, which will avert people from using threads. Because who will want to use an infrastructure that makes working Lisp programs unpredictable when run from a non-main thread? > So, to summarize, it sounds like your issue with not locking processes > to threads is: > > Without locking processes to the creating thread, a process's output > can be read by some other thread during the wait, and then our thread > will hang forever if it calls accept-process-output after the wait > ended. Either "hang forever", or fail to work because the expected output is "stolen" by another thread, or run the process filter in the context of another thread (where, for example, things like the current buffer and match-data are different), or some other such unexpected conditions. > This is unfortunately not detailed enough to translate into code. I've > never seen a real-world program which would be vulnerable to this > problem, as described here. I can make up toy programs which meet this > description which would hang, but I'm not sure they're actually what > you're concerned about. Especially because they aren't anything like > real-world programs. I toy program that looks valid and runs in a single-threaded Emacs, but hangs or fails when run from a non-main thread is already a problem. Whether it is interesting for us depends on the program. A toy program which demonstrates an issue that real-world programs will meet is interesting. In any case, it is clear to me, and should be clear to anyone else, that taking a Lisp program written for a single-threaded Emacs and running it from a non-main thread will be made easier if the output from the sub-processes started by that program will be read only by that thread, because that is closer to the assumptions under which the original code was written. > Could you give some more details about the scenario, so I can try to > write a test demonstrating the problem? Or could you point to a > real-world program which is vulnerable to this problem, so I can turn it > into a test? I've never used or debugged a real-world program where these aspects come into play. My experience is almost exclusively with small "toy" programs and test programs, the ones we have in the test suite and also those submitted as part of relevant bug reports. You may wish looking at running the Gnus function that fetches articles from a separate thread (I think someone tried that at some point), and you may wish talking to Michael Albinus, who tried using threads in Tramp (I think he has that on a branch somewhere?). From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2025 16:42:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.1757004081518 (code B ref 79367); Thu, 04 Sep 2025 16:42:03 +0000 Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 16:41:21 +0000 Received: from localhost ([127.0.0.1]:48645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuD1T-00008E-T0 for submit@debbugs.gnu.org; Thu, 04 Sep 2025 12:41:20 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:48379) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuD1K-00007g-D5 for 79367@debbugs.gnu.org; Thu, 04 Sep 2025 12:41:12 -0400 From: Spencer Baugh In-Reply-To: <86ikhykem2.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 04 Sep 2025 07:48:05 +0300") References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> Date: Thu, 04 Sep 2025 12:41:04 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1757004064; bh=THTco5ZIsEpakAcVVG6oWH2J2evVGre5N19ZItjBALw=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=yJT9oXaSfUeFnprc0auP23TP/R/67OyXwPGrRKZHYbzkChjZhilevV8gBOrJpGN+f sTGd/AJ6h+4smTwmAcyF5NjnH0Kc5J5yrxGa20hYvfT5pueUMQsOX32oTry6v3GWKD 1/cbheoq6xUtJx4Ijt2WMUo4FLSCweaSPYOITxUald6a+tytxMDfiNNT8rr8AKWrnI ltfdfEK8lttdCRO0qQlDhCzClVb9Y4I/om5UG+NzWUWWWCDHiSXhEWcVxb7Z5uUKHA EL5U74Iza5m00T8guOeDhtKFUcylSGInqjfCmEBJVVWJFWANkZvvk+Zbs+mI6RHXrH bdkF+MNw/4eqA== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev >> Date: Wed, 03 Sep 2025 13:07:08 -0400 >> >> Eli Zaretskii writes: >> >> > + /* make_process calls pset_thread, but if the server process is not >> > + locked to any thread, we need to undo what make_process did. */ >> > + if (NILP (ps->thread)) >> > + pset_thread (p, Qnil); >> >> We should probably just unconditionally do: >> pset_thread (p, ps->thread) >> here. > > That's a bit dangerous, since the I/O descriptors of the new process > are not yet set, so the call to pset_thread there, in case ps->thread > is non-nil, would do a partial job. We could instead move the > pset_thread call to later, where set_proc_thread is called, but I > preferred to undo what make_process did ASAP. I'm confused. - It's just duplicating what make_process did, so I expect it's essentially a no-op, just simpler code. - Why would it be dangerous even if that wasn't the case? We're still setting up this process, it's not visible to any Lisp code, so what bad event could even happen? >> >> > /* Build new contact information for this setup. */ >> > contact = Fcopy_sequence (ps->childp); >> > @@ -5117,6 +5121,19 @@ server_accept_connection (Lisp_Object server, int channel) >> > add_process_read_fd (s); >> > if (s > max_desc) >> > max_desc = s; >> > + /* If the server process is locked to this thread, lock the client >> > + process to the same thread, otherwise clear the thread of its I/O >> > + descriptors. */ >> > + if (NILP (ps->thread)) >> > + { >> > + eassert (!fd_callback_info[p->infd].thread); >> > + set_proc_thread (p, NULL); >> >> Yes, this is the right assertion. But it should be outside the if/else >> because it's true even if ps->thread isn't nil. > > I don't mind moving it out. Great. >> This whole if/else conditional should probably be just: >> >> eassert (!fd_callback_info[p->infd].thread); >> if (!NILP (p->thread)) >> { >> eassert (XTHREAD (ps->thread) == current_thread); >> set_proc_thread (p, XTHREAD (p->thread)); >> } >> >> It's not necessary to call set_proc_thread(p, NULL) in the other case >> since it will just set .thread to NULL, which we're already asserting >> anyway. > > The assertions compile to nothing in a production build. Then maybe we should turn this assertion on by default in production builds, since threads are still encountering problems, and it would help catch problems. Zhengyi says he saw in a debugger this field was set to non-NULL at this point, which indicates a bug, so it would help tracking that down. > Also, I don't like the caller to assume too much about what > set_proc_thread does, it's not future-proof. So I'd prefer to leave > that call in place. That's fair. Though, I think the way set_proc_thread works is a bit confusing, so I'm inclined to refactor it in the near future anyway. But, the reason I'd like to take out the call is that it will mask errors created elsewhere by clearing the field. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2025 19:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175701377332511 (code B ref 79367); Thu, 04 Sep 2025 19:23:02 +0000 Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 19:22:53 +0000 Received: from localhost ([127.0.0.1]:49328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuFXn-0008SG-Tg for submit@debbugs.gnu.org; Thu, 04 Sep 2025 15:22:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49384) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuFXc-0008Qn-TN for 79367@debbugs.gnu.org; Thu, 04 Sep 2025 15:22:47 -0400 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 1uuFXV-0007xU-D2; Thu, 04 Sep 2025 15:22:33 -0400 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=AtkYKyX/TqSsywJ6qxsMUnVScmGEk4Pv5yx8VvOD3UA=; b=em4i19I3cGJV 1I1LhVqUj4vQtiuf5tQLo8XDy4V2iT4RS8OU+ZvLAxz1Ocv7MP3gyYRLQxXtay/BlFf7UaUx+H/8h mW8RqAG0lTK2y2o6TEsayC+RY93Pc4nNQwHvlJDft6nqlInx99oSoFNArRnqtVRFcQz8mKnlwxjh9 evFEkKLsB1C5Cc0VM2RbcKmhPQ4kqIjZjHZLVldBz1y5scrEA5iW50uitxecjuH6XHYO7zdlCmGaR rN+J9AkDvXIw9zVlGYoj2jShLz0vRSZyJwDZtztp78y3IEyItNTAA8KFPI3ehIZ4ubuNoVC5LyUCZ /xyAtMzB2U/seqpKTTUVUw==; Date: Thu, 04 Sep 2025 22:22:29 +0300 Message-Id: <86zfbahvka.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Thu, 04 Sep 2025 12:41:04 -0400) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev > Date: Thu, 04 Sep 2025 12:41:04 -0400 > > Eli Zaretskii writes: > > >> We should probably just unconditionally do: > >> pset_thread (p, ps->thread) > >> here. > > > > That's a bit dangerous, since the I/O descriptors of the new process > > are not yet set, so the call to pset_thread there, in case ps->thread > > is non-nil, would do a partial job. We could instead move the > > pset_thread call to later, where set_proc_thread is called, but I > > preferred to undo what make_process did ASAP. > > I'm confused. > > - It's just duplicating what make_process did, so I expect it's > essentially a no-op, just simpler code. > > - Why would it be dangerous even if that wasn't the case? We're still > setting up this process, it's not visible to any Lisp code, so what > bad event could even happen? Having some part of server_accept_connection, even a small part, run with the new process locked to a thread introduces a window during which the process is in an incorrect state, and I would like to avoid that if possible. Admittedly, in this case the window is very small, but it is still there. Some future changes could actually trip on that. > >> It's not necessary to call set_proc_thread(p, NULL) in the other case > >> since it will just set .thread to NULL, which we're already asserting > >> anyway. > > > > The assertions compile to nothing in a production build. > > Then maybe we should turn this assertion on by default in production > builds, since threads are still encountering problems, and it would help > catch problems. Production builds are not for catching problems, at least not in my book. A production build should try to avoid aborts if possible, because an abort might mean loss of edits. That's why we have eassert to begin with: we use the period of time that code is on the development branch to catch errors and fix them. > Zhengyi says he saw in a debugger this field was set to > non-NULL at this point, which indicates a bug, so it would help tracking > that down. Building with --enable-checking will allow us to do that. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2025 19:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17570142441905 (code B ref 79367); Thu, 04 Sep 2025 19:31:01 +0000 Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 19:30:44 +0000 Received: from localhost ([127.0.0.1]:49357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuFfP-0000Ue-9c for submit@debbugs.gnu.org; Thu, 04 Sep 2025 15:30:43 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:42659) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuFfI-0000UI-Tw for 79367@debbugs.gnu.org; Thu, 04 Sep 2025 15:30:38 -0400 From: Spencer Baugh In-Reply-To: <86zfbahvka.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 04 Sep 2025 22:22:29 +0300") References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> Date: Thu, 04 Sep 2025 15:30:30 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1757014230; bh=CieaTAQqhc47bvZXRrlaAJAFQ9SzsdB6iANvkSAcsIQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=kYMHNYJOxw2oLLTPSMNuau46WA1F3dzDu0qZk+AsQtLASeBA7SyCtXa8ouyYExMEg qPG+u+4mc8Q9+y42qimoVU9FHCAh9EV9eSGZyUP0uy5EEuP7wTkWowQCyvBd5KKBtr XNmKS7BnUgiRJzSI83f9udwYFeBP0pK/5NOqGVGKsroE2cNVtgAt2m+4OijnmaNCpa Zp/+MuY5EMiZsndLmbehXecSqbgOf6oSZLKFp2n+4j6ymcZbPimeF1ZIbSfCr3dvcC YPu9yz/MbJmeXkR+Q4CH9l3ipqENZ7VWyd8tKSEhYD96O/5WlGYpuVyR9tbfI58Llt +u+Fd2UUnufFw== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev >> Date: Thu, 04 Sep 2025 12:41:04 -0400 >> >> Eli Zaretskii writes: >> >> >> We should probably just unconditionally do: >> >> pset_thread (p, ps->thread) >> >> here. >> > >> > That's a bit dangerous, since the I/O descriptors of the new process >> > are not yet set, so the call to pset_thread there, in case ps->thread >> > is non-nil, would do a partial job. We could instead move the >> > pset_thread call to later, where set_proc_thread is called, but I >> > preferred to undo what make_process did ASAP. >> >> I'm confused. >> >> - It's just duplicating what make_process did, so I expect it's >> essentially a no-op, just simpler code. >> >> - Why would it be dangerous even if that wasn't the case? We're still >> setting up this process, it's not visible to any Lisp code, so what >> bad event could even happen? > > Having some part of server_accept_connection, even a small part, run > with the new process locked to a thread introduces a window during > which the process is in an incorrect state, and I would like to avoid > that if possible. Admittedly, in this case the window is very small, > but it is still there. Some future changes could actually trip on > that. It's already locked to a thread by make_process. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2025 22:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Spencer Baugh Cc: i@fuzy.me, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17570260375289 (code B ref 79367); Thu, 04 Sep 2025 22:48:02 +0000 Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 22:47:17 +0000 Received: from localhost ([127.0.0.1]:49632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuIjc-0001ND-FV for submit@debbugs.gnu.org; Thu, 04 Sep 2025 18:47:17 -0400 Received: from fhigh-b5-smtp.messagingengine.com ([202.12.124.156]:34495) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuIjX-0001Mq-7P for 79367@debbugs.gnu.org; Thu, 04 Sep 2025 18:47:12 -0400 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id 1CD977A0602; Thu, 4 Sep 2025 18:47:05 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Thu, 04 Sep 2025 18:47:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1757026024; x=1757112424; bh=xszehEW3EcXjL5BPh4zenXMBAmQU/MAQ1ym1DtEBJR0=; b= CYO+IJYjtqw8ZixJeY+3uUj/HF+4REzZaS34GbccOK6j/uty6r5Y+xj7T6OVwgUe VM43AejfSgaTDT2lo6/byp7pxdnrxA2405UnpjBPXpfJwJGMPvoYaesjh1QEg/le Wb8ZWTaxLUi+4Rkw54E68KaiN62y+WrwsQVI08xfyRV2zJwidtVGUqFnyavSLVHJ Io6JQyNx2kb2xTNnxc529i4ehLtkMOo10nZzabLDqRDEZQvA60zqwbii6vRkMRRf f9HU4PrZRwhwoELu3VzVi12l9lmXi3JgDF49gGSjU5CSoYImaxBvYB7YDN/Vizfn taxfaBwN3m9VpaqPAv6f/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1757026024; x= 1757112424; bh=xszehEW3EcXjL5BPh4zenXMBAmQU/MAQ1ym1DtEBJR0=; b=g PiSiOOpnbV67FDg7n1A+YulZgXDdp4MB/ZkBPzkBLNijqgwlbTsZD5+KwkbX8dJR wF6box9Gtw+vFNOTt0PWvR/btleigViJpnTIb/lbv1stTmn9kpKfUvFTlolHlVOQ /aMZKnIV4M4dsWD1+lepoZ2RlsKgoVifHNhLyUwJwdpvW6nE11FlMF4LN2+j4WRH cPcsA52gHynC5tJrrB3rqouXYgH+hGxOLSCMqcBXs1olHvjsf7POni3OhTn75nVo bqTyG58iGX7BRp6J/eh/bcWG+7uWFxZKt2FpblL2wC2vZVf7P1z67B+FnjdZmdGB JfZVr/7TNj58/niCKdi0w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdejvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh ephfegudfftdevhfelveetteehffehvddujedvjeekffeljeetleejieegvedtjedtnecu ffhomhgrihhnpehgnhhurdhorhhgpdhgihhthhhusgdrtghomhenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdr uggvvhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoh epvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhr vggvthdrtghomhdprhgtphhtthhopehisehfuhiihidrmhgvpdhrtghpthhtohepjeelfe eijeesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 4 Sep 2025 18:47:02 -0400 (EDT) Message-ID: <3aefa906-5bfc-4459-8653-4b2f981fd4b0@gutov.dev> Date: Fri, 5 Sep 2025 01:47:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86ecsmkd6p.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86ecsmkd6p.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 04/09/2025 08:18, Eli Zaretskii wrote: >> This is unfortunately not detailed enough to translate into code. I've >> never seen a real-world program which would be vulnerable to this >> problem, as described here. I can make up toy programs which meet this >> description which would hang, but I'm not sure they're actually what >> you're concerned about. Especially because they aren't anything like >> real-world programs. > > I toy program that looks valid and runs in a single-threaded Emacs, > but hangs or fails when run from a non-main thread is already a > problem. Whether it is interesting for us depends on the program. A > toy program which demonstrates an issue that real-world programs will > meet is interesting. A toy program could be a good example if you can choose a specific one and point out how it related to a real program (e.g. being a simplified case). We could take such a program and see whether it indeed exhibits issues multi-threaded (when unlocked) but stays reliable in the single threaded case and multi-threaded when locked. Both aspects seem testable. >> Could you give some more details about the scenario, so I can try to >> write a test demonstrating the problem? Or could you point to a >> real-world program which is vulnerable to this problem, so I can turn it >> into a test? > > I've never used or debugged a real-world program where these aspects > come into play. My experience is almost exclusively with small "toy" > programs and test programs, the ones we have in the test suite and > also those submitted as part of relevant bug reports. You may wish > looking at running the Gnus function that fetches articles from a > separate thread (I think someone tried that at some point), and you > may wish talking to Michael Albinus, who tried using threads in Tramp > (I think he has that on a branch somewhere?). There two are interesting. Last I heard, Tramp's branch wasn't stable for everyday use (citing hangs, IIRC), but it has a set-process-thread call, locking connection's process to thread explicitly: https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/lisp/net/tramp.el?h=feature/tramp-thread-safe#n2759 For Gnus, I can't find a branch in Savannah, but Dick Mao's Emacs fork claims non-blocking Gnus among features. And it unlocks nnimap's process: https://github.com/commercial-emacs/commercial-emacs/blob/6d3ff0428337a734136d00cf2294aa9d3dbcff0e/lisp/gnus/nnimap.el#L592 Maybe someone could test it out. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 05:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.1757051665345 (code B ref 79367); Fri, 05 Sep 2025 05:55:01 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 05:54:25 +0000 Received: from localhost ([127.0.0.1]:50550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuPOz-00005T-1M for submit@debbugs.gnu.org; Fri, 05 Sep 2025 01:54:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46664) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuPOv-000059-Jv for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 01:54:22 -0400 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 1uuPOo-0000Kx-Ko; Fri, 05 Sep 2025 01:54:14 -0400 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=dr5ZWENIEYqfu6awUyBNdEtEL+f2M0f+DWTSIrUcz2s=; b=rr03ZzYj1lGm 5iLZ6z8NveOn/+zLYZjXR+xhyQ3EsHfq8XBwkx7FLZojUXQqdbsmKUXkkDJHHfg3i6m8RoTiyy9Pj TTl9bw27nOPXwAJTsMn6cj9y8muGdKYl9ddDPOXPki8zNyBdZkOeilJVyouYOglDWkMVDPzl8pfih V9fPVaFeXiJUv61GvqxTiCrcZdGM2xXdXSLNfw7x/DZH+yZfayBY+OCf5/VztRJ1lPOs5cGlOLydl Wc+7v5dTxfftIbusRoH59+TizLBeb+RKLKvolRTgLFTYOZVcbtGtgI9WBFij9fdA0wab/MhdAWm0c pnkwEqPPRGoYnexFTyM3+w==; Date: Fri, 05 Sep 2025 08:54:11 +0300 Message-Id: <86wm6digvw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Thu, 04 Sep 2025 15:30:30 -0400) References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev > Date: Thu, 04 Sep 2025 15:30:30 -0400 > > Eli Zaretskii writes: > > >> From: Spencer Baugh > >> Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev > >> Date: Thu, 04 Sep 2025 12:41:04 -0400 > >> > >> Eli Zaretskii writes: > >> > >> >> We should probably just unconditionally do: > >> >> pset_thread (p, ps->thread) > >> >> here. > >> > > >> > That's a bit dangerous, since the I/O descriptors of the new process > >> > are not yet set, so the call to pset_thread there, in case ps->thread > >> > is non-nil, would do a partial job. We could instead move the > >> > pset_thread call to later, where set_proc_thread is called, but I > >> > preferred to undo what make_process did ASAP. > >> > >> I'm confused. > >> > >> - It's just duplicating what make_process did, so I expect it's > >> essentially a no-op, just simpler code. > >> > >> - Why would it be dangerous even if that wasn't the case? We're still > >> setting up this process, it's not visible to any Lisp code, so what > >> bad event could even happen? > > > > Having some part of server_accept_connection, even a small part, run > > with the new process locked to a thread introduces a window during > > which the process is in an incorrect state, and I would like to avoid > > that if possible. Admittedly, in this case the window is very small, > > but it is still there. Some future changes could actually trip on > > that. > > It's already locked to a thread by make_process. I feel that we are splitting hair, so I went ahead and installed the last agreed-to version of the patch. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 06:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, Spencer Baugh , dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175705512313922 (code B ref 79367); Fri, 05 Sep 2025 06:53:02 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 06:52:03 +0000 Received: from localhost ([127.0.0.1]:50756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuQIk-0003cT-52 for submit@debbugs.gnu.org; Fri, 05 Sep 2025 02:52:02 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:41395) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuQId-0003bs-Nm for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 02:52:00 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id E635C443B5; Fri, 5 Sep 2025 06:51:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1757055109; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=po79a34z/yO7I1LR4Uhe5iDDYtk5zhXz2t4gPqJvEOM=; b=c5S7CcQqyuqqOefAkP3EMR85YMMEnmldWcgGMuno6P/1Bq4sfbqAQGVI8XqFdVfxEXkUcR FN8NOGBck+qPm14FA9GHfDee9R8npW5CbfglzUpDGCKG/1CVNZ4vG3bXMk29caN8FVa8Gb UNLsJvGLvSAiekqEMVojSiCJcJlV6FFTTvC+h55MOFgE97yWCGgfXnXngC0JCeUvJoGOvt JFsiOCj0B+JqYiL2C0nWAjLD0ydxo2neP18HGhUltp5US3MDPsEAiF0fvnrX25bCY6QYlc 9tyObV8Ml7lPPSMrHbhyv1REfr1b6+U++EFQaH/ZZgr4aOcX2S2jlwLRil6G7w== From: Zhengyi Fu In-Reply-To: <86wm6digvw.fsf@gnu.org> References: <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 05 Sep 2025 14:51:42 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdekvdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhgffffkgggtsehmtderredtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeejledttedugeeviedtkefgvdffgfefleevgfffffeuvdevieejvddvieegffeuvdenucfkphepudelvddrheeirdelledruddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelvddrheeirdelledruddvpdhhvghlohepjhgrmhgvshdqfhhuqdhusghunhhtuhdvgedtgedpmhgrihhlfhhrohhmpehisehfuhiihidrmhgvpdhnsggprhgtphhtthhopeehpdhrtghpthhtohepughmihhtrhihsehguhhtohhvrdguvghvpdhrtghpthhtohepjeelfeeijeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehisehfuhiihidrmhgvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev >> Date: Thu, 04 Sep 2025 15:30:30 -0400 >> >> Eli Zaretskii writes: >> >> >> From: Spencer Baugh >> >> Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev >> >> Date: Thu, 04 Sep 2025 12:41:04 -0400 >> >> >> >> Eli Zaretskii writes: >> >> >> >> >> We should probably just unconditionally do: >> >> >> pset_thread (p, ps->thread) >> >> >> here. >> >> > >> >> > That's a bit dangerous, since the I/O descriptors of the new process >> >> > are not yet set, so the call to pset_thread there, in case ps->thread >> >> > is non-nil, would do a partial job. We could instead move the >> >> > pset_thread call to later, where set_proc_thread is called, but I >> >> > preferred to undo what make_process did ASAP. >> >> >> >> I'm confused. >> >> >> >> - It's just duplicating what make_process did, so I expect it's >> >> essentially a no-op, just simpler code. >> >> >> >> - Why would it be dangerous even if that wasn't the case? We're still >> >> setting up this process, it's not visible to any Lisp code, so what >> >> bad event could even happen? >> > >> > Having some part of server_accept_connection, even a small part, run >> > with the new process locked to a thread introduces a window during >> > which the process is in an incorrect state, and I would like to avoid >> > that if possible. Admittedly, in this case the window is very small, >> > but it is still there. Some future changes could actually trip on >> > that. >> >> It's already locked to a thread by make_process. > > I feel that we are splitting hair, so I went ahead and installed the > last agreed-to version of the patch. I got an assertion failure when testing the latest master. --=-=-= Content-Type: text/plain Content-Disposition: inline Thread 1 "emacs" hit Breakpoint 1, die (msg=msg@entry=0x55555588fd38 "!fd_callback_info[p->infd].thread", file=file@entry=0x555555879464 "process.c", line=line@entry=5127) at alloc.c:7302 7302 { (gdb) bt #0 die (msg=msg@entry=0x55555588fd38 "!fd_callback_info[p->infd].thread", file=file@entry=0x555555879464 "process.c", line=line@entry=5127) at alloc.c:7302 #1 0x0000555555806a6a in server_accept_connection (channel=14, server=0x555556bce4bd) at process.c:5127 #2 wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5989 #3 0x00005555555a3188 in sit_for (timeout=, reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:6978 #4 0x000055555570b8ba in read_char (commandflag=1, map=map@entry=0x555556aa02b3, prev_event=0x0, used_mouse_menu=used_mouse_menu@entry=0x7fffffffd8bb, end_time=end_time@entry=0x0) at keyboard.c:2925 #5 0x000055555570e164 in read_key_sequence (keybuf=keybuf@entry=0x7fffffffda10, prompt=prompt@entry=0x0, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, disable_text_conversion_p=false) at keyboard.c:11146 #6 0x000055555570feda in command_loop_1 () at keyboard.c:1424 #7 0x00005555557a5ba8 in internal_condition_case (bfun=bfun@entry=0x55555570fcb2 , handlers=handlers@entry=0x90, hfun=hfun@entry=0x555555700325 ) at eval.c:1690 #8 0x00005555556f8b3b in command_loop_2 (handlers=handlers@entry=0x90) at keyboard.c:1163 #9 0x00005555557a5aa7 in internal_catch (tag=tag@entry=0x118e0, func=func@entry=0x5555556f8b14 , arg=arg@entry=0x90) at eval.c:1370 #10 0x00005555556f8af1 in command_loop () at keyboard.c:1141 #11 0x00005555556ffdf1 in recursive_edit_1 () at keyboard.c:749 #12 0x0000555555700181 in Frecursive_edit () at keyboard.c:832 #13 0x00005555556f8650 in main (argc=6, argv=) at emacs.c:2629 (gdb) fr 1 #1 0x0000555555806a6a in server_accept_connection (channel=14, server=0x555556bce4bd) at process.c:5127 5127 eassert (!fd_callback_info[p->infd].thread); (gdb) info locals buffer = 0x0 contact = 0x555556a903e3 host = 0x30 service = ps = p = 0x555556bd4c08 s = 16 saddr = {sa = {sa_family = 1, sa_data = "/run/user/1504"}, in = {sin_family = 1, sin_port = 29231, sin_addr = {s_addr = 1966042741}, sin_zero = "ser/1504"}, in6 = {sin6_family = 1, sin6_port = 29231, sin6_flowinfo = 1966042741, sin6_addr = {__in6_u = {__u6_addr8 = "ser/150425139/em", __u6_addr16 = {25971, 12146, 13617, 13360, 13618, 13105, 12089, 28005}, __u6_addr32 = {796026227, 875574577, 858862898, 1835347769}}}, sin6_scope_id = 796091233}, un = {sun_family = 1, sun_path = "/run/user/150425139/emacs/server\000UUU\000\000\000\000\000\000\000\000\000\000\370?UUU\000\000?pUUU\000\000\300\207\272h\000\000\000\000\001", '\000' }} len = 35 count = args = {0x7fffffffcf84, 0x55555686ace4, 0xa, 0x5724a633450d2100, 0x7fffffffd190, 0x555555a714e0, 0x555555c2a7f0, 0x0, 0x400000000a000000, 0x400000003f000000, 0x7fffffffd1b0} nargs = host_format_in = 0x7fffffffd004 host_format_in6 = 0x7fffffffcfe4 procname_format_in = 0x7fffffffcfc4 procname_format_in6 = 0x7fffffffcfa4 procname_format_default = 0x7fffffffcf84 name = proc = 0x555556bd4c0d dash = nl = host_string = open_from = (gdb) p *p $3 = {header = {size = 4611686018578444307}, tty_name = 0x0, name = 0x555556b274c4, command = 0x0, filter = 0xef8cc0, sentinel = 0xef74e0, log = 0x0, buffer = 0x0, childp = 0x555556a903e3, plist = 0x555556a90163, type = 0xd4d0, mark = 0x555556bd4d25, status = 0xf810, decode_coding_system = 0x0, decoding_buf = 0x0, encode_coding_system = 0x0, encoding_buf = 0x0, write_queue = 0x0, stderrproc = 0x0, thread = 0x5555558eb005 , pid = 0, infd = 16, nbytes_read = 0, outfd = 16, open_fd = {16, -1, -1, -1, -1, -1}, tick = 0, update_tick = 0, decoding_carryover = 0, read_output_delay = 0, adaptive_read_buffering = 0, read_output_skip = false, readmax = 65536, kill_without_query = false, pty_in = false, pty_out = false, inherit_coding_system_flag = false, alive = false, raw_status_new = false, is_non_blocking_client = false, is_server = false, raw_status = 0, backlog = 0, port = 0, socktype = 0, dns_request = 0x0} (gdb) p fd_callback_info[16] $4 = {func = 0x0, data = 0x0, flags = 9, thread = 0x555556c5d598, waiting_thread = 0x0} --=-=-=-- From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 10:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: i@fuzy.me, Spencer Baugh , Eli Zaretskii , 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17570688814466 (code B ref 79367); Fri, 05 Sep 2025 10:42:02 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 10:41:21 +0000 Received: from localhost ([127.0.0.1]:51945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuTse-00019y-T7 for submit@debbugs.gnu.org; Fri, 05 Sep 2025 06:41:21 -0400 Received: from mout.gmx.net ([212.227.17.21]:39469) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuTsZ-00019c-Gp for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 06:41:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1757068853; x=1757673653; i=michael.albinus@gmx.de; bh=Ta/ATF7VtYebxIlNGjBY9pWCRRJUvkgzbxdmA5/oJZ8=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=LJmgI7fVYB9qhtNx0p6cyQivCS7vnJlKksAlVmsl+4fUxlJ+dIv6KYy7x7iHX+WV 0eM3PdNnlUJBFu32MfqMKKf8KdpfNYAU+LVuIpaSBWNFumCHV2JO5B0PR6cJRE80d IYU2IwKUE1VO8zgecEIB9YNdPvf0NVhqovhRf1DLM2bUo3URuxpCUw9O00/xaAs8w phK5yfLWhbdHGp/eE2UqXDaqa4Kn3x35+0OYsE14JavT0YXLlm+PBZvzLpr0FyiOG 3AxG5zY2qXIdH4VEI5vDUUDMaPbigyCmr3e/IvN9ehoVMkxML0+bmoD/sr0jbhZjq wfruFsl82MoaadUzQA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from gandalf.gmx.de ([185.89.37.61]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1McY8T-1uKJFA362H-00hlHo; Fri, 05 Sep 2025 12:40:53 +0200 From: Michael Albinus In-Reply-To: <3aefa906-5bfc-4459-8653-4b2f981fd4b0@gutov.dev> References: <865xe1m3uu.fsf@gnu.org> <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86ecsmkd6p.fsf@gnu.org> <3aefa906-5bfc-4459-8653-4b2f981fd4b0@gutov.dev> Date: Fri, 05 Sep 2025 12:40:52 +0200 Message-ID: <87jz2d41xn.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:9FoKcLE9Zjsq0RpYwKXRvxlNwIxYk3YeKVOGvsDFLcq7duMY11M srL+bnxOsplYO2vbw+ujuTls1MStSoVm9CtqnwvQQyUB/kb7MbkAAG4ppJI2/QK0l1OuZbf zLlUhwc42di4knxftZHng5Udfb1D7gU9dgavpVGczaEhLzKWu3NURBIKbCC6CXVoWLKd6Wc eYur/5f1mkMMf9FEk1quA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:dMasWmj2RUM=;DZ+IynfhDAEMrEFGaTq9jyBCfUq 1KAlD1f00OUX0Ek7tL/XMgrrk1S7MmZaFJU7K9Cb4NOPXevQkeTz06hhaBomiIaemdVG3awY1 4KIQ9nU2yNEtvmiK1XuTpWUNnzD3VT6WSxBSybPFc48yXKTsosIl7pa6xGg7cUuiSmUWVNnRd 1Wkdppw++3VNih8YqK94ufAZPQQmUnd/TygGbST/Rhm5M2HXhSmtFincxaB6s7LWK6sY9Qvsf DIvtnsZ539nAh7Z9boKB12+Fq/AU0Bjtm6QM5HFS//ZB5vY6idbDJGpzjlEdRozH8IpVMWKXP qMy33PQzLmnk1A6S0L1nenMrytj84wWUHaJdSVLUnlpb5a5MlMHUpp6h0BI1IUCPl+oUtho/Y MdccJdSZ1T1wfHvvk9RrweQvWZk3uA+hwbSujNAMqnF9aA0l5cF+DnNZ91H/dh02miI8yFf9V cJjhX4u4RnWu0JubiVpW3N2mubgrr66jAVWXT7mg8TLW8c85CN/Til7IuaT7vnoiU5saMlCdh N+vDv/H+bAoj0N2+Hlnzp1Wog6oEDfStiRXdCaAha6yGdW2ySM9Y+s03MdmahiH6KXrZavSpn JV8cAe5yWJAWMp42uOUYlTvmtBXTGbGQtBmw907j/2dAETRXSNsh8KJlRX1j/beSGDcp4nj4R psvgDq1OfG08lP6WXdWOTDBuA2qVjAjShn7K/z4g0WmlM/fTI7+d/h2rMmdxVByyrEkE7OAjf sjikz70ks+1YoyXkkCvmAK5acjOTkodEF3O3VRFa192adk3xOoei9ZJfd+kYXZ02v+SRB42RK rOmjBaYq9o3bRHKNnPQeFo/zrw6gWTb1wuWZgUiQpEMF1j1LyyjfaBqhNWRJNvrgjI6tWwJ6b MmGdcJsOO8dh9scLmxW3F1PmxacuNZ2FPGj3xn5AJ9Gt0a51QYa3UI558KNHnIalVdG4tQkyJ F+3vuisCIY326aTx/SnzpmHdE8rVC+Jggp8ut8E9kfMLAij9gBr/IDQBUTlxmj2eKItDyROV+ TyxmwDN42UNOOFR9/Vl17ZFnulW3PBuW7S/n7yvew3g7T2xStHOYq9k870Uv/2my3GYDtx/eM oGTE2+/CA5B5oGt3Fx9IERNFYaSvmieNbaAzWyUx4GH+RYLhENuvnhvs1kKAs3Zy+N2WO6j0t ALeaUES1Oyu+z4RORFu3L6r2zLlIvJ29Zt/lCIMFCjx/oiAJel0lwNt5Kp7IRIPHxk7ODNTkS jCFbN2PBgvy0AdjvUL/garIdpTshqDrSeDNiVbZ6XMRPsLr9eI0tw7WDxqvVGLuarvvQ1DhzY pM0avInJUAB1knOLc52h90yOO2VWH4JObPJf1sEqRejerqL3A/WV5fzYtkYm7IEpnJd04EKno p0m12njAE3QIftW5knQQsPR/y+gysh2tPRH9/K4nEtehFyTOgaqq9AbSXF9OXRv0H9L4wY83Y gxNNY1Twn4bvdgvoifOkoLyOqBpW0/dPXr1Htm2dMLBr5v6QQsi/q8oIAGVAE1HjyKwGC2piO WRKvr0GIou86sba5J3ly8mr4Zw5UfsNwDxqZvRlC0xVZdLSWI59wyXxcx8T/nM/hQQQOwbgSe ZP/EVuyucRgXWd4fBArYotSkZEQOxSQXunsbUIYljEjsILTimn8ZKR+ADOndiKxFQ3yphxKPy UeBBrsFLWPcNvwRb3IRqzpg5/Jxei4OgVrMTvynmMwuAf6aiWp4L2IQ22os/hOXbvQxKHugyA qaJyTO+NJnXkDPJ/FRXt5iORahcpIh+DLDX8lQ00QdF3OH+NS667/3kOb4F+S5w4BsapGxG8i Rd19bY5txFLpETu06EeLf0AQeFmkpwz4ENuwPYk4Fct3I1k3L8Q5bPMb3NNT4v86y0rVbYReZ gn19bHvKCAosF4fE8RRK53fiZHBHuQSFkpk1RhPkkMlw3iXm1HFCRDn0Et8AGPfeKpLHcbSpu dYdkkE+Rth3rmcGG99x+XSY96N2v3CUvhXlDOWZ//ZX3rBgoo68y0jPwUwWRpkQzhOojQxPHI NRAynsoMjpaAnt/1U8eMiAn9gxgSgQyLor4tpozOapUEdgcXEO0GEjIK9ZUZyIrJp0gQWi3y0 rfXC43w44c7SbC4lGWIMourlprfVlQzdRnccRkra13zU4tdMVG8V37pgdk2zQWR1o8qgs87kf M8NPmfG1xxQrwVZ83eXEcYCetMs8NsS+3pYS/toGMq0c1jXbhgvN6bXsz6kVsF7l5Omr065CF GvrWdJsbEZkcWIKnmV/8UBVLDWgaslCJm2tkGaW/xWb7oD0MgnKtDCcLUcQ1g1l4yroou1Gai U/L5yAtN92UoYzvawHfpGCS3R9neYM79mAewTrPv5e/CnkvX5ACsTAnxMYTx+7ICKV/7FJtB6 5Gld7ZLgCmGOgrNMpEJZSO1y1l97G7F9vHLREqXWesZ0A3g0yQxBBHeJAqcgpns56Ky8rhw2i 59VwbgSMfeRoieOehz682dDUwI1mk7Xqs31qYO6tIs71Eu/dU2qtwn6UGDV/TxyEbnHDYQXj+ RyAuX2eujxFkfS24XN1hMTkBucU3ITT4Q4JDSOjOmh8BWtGDSyH3nts1vEHg1ta8FiIg9oZsT ZERQNO+Hruq1hYAh1H+J3l/gugbeeieiGJ+DgyL/I2czCrczd4lZxF+nW13uiYz7iiNyYm34b 2WxATUc7+cSg67p7krgEYkO8LIitorDMtqj3XgXxj8HUf+VjdnzEIurK53eb/TZocsEKkRh8s wXaM6eDO7nInD9U8dzxTUPJFuuR3yEoEwYOJMj4xm56jmClidXZ1kWq9JxRzTMdso28zN2bAV QgTWBF2VgM1UnH6sU5YrdoV165G0aGjv/PL94/N05LiUkY5EMcNEaG+QD0HjdTPCUs6V6JhV2 Z7lncFwke5YWTH9DqJhcqjmO0DJx3ePAIhN7SNeJ2I+H9KGQdyYvA6dYecBQJ5XCMMBDX/Gua O9huo36+1BiNqW6CcMwqj1QsuqeU3fkAWSBQFAzr6uptEUH5wIUKJAIDsUzUgURXJ8JIaNqnB MXxaXTr5f8ACWMcI0YrVp0rJFCD5Gq0TLUkB5tr9H9vXJ6g7uyUjDwkzZSI48LH7DaGIZ0ouX LSsVyBtc9X+4SBnUYu86/THJa/gves5i7zEC+ZVTXokJ5dGSYbSled9gczRyrO3eiGkpELG7x 3NVZqt/Z59D7iKPHOdNYqRYjotEnVfyqRVFV1hIiDIQfIoP9XjKetpe29ApCnVVZhOQNd2c+u cQO4pe3N+3I6OuxgjgMrmvyp2YDBZTts9LEfF26Gkw3629jJW7YSc1BGjlxxbm4JUzsI7jIRR OiythRjZBGrrPiIfsLwV7xxN46SjTgfmh0gaEJ2viBH+aTI/U6L/+SFI+G2Uonaf9He6ndaCm 9lU9rYAzBrMobm/9mlFFGbFZnwHCv0qevnTSrzJKTGZ6ere/2+Vgf+R64UULPkmtbsPXfeZJU 0KmLqFIvUkJXCVVshnL0ze1CbXQkRGb5kBL0uQr88LZn5zBsfpJtpJ+J4zhax8dzWAMDU1VHI 5D8xm/Q/TsPqMw5toB2YVPiyyerTLNoLDe4HplgKnaItNEvhRBKY3zHfpCdexYTT6D+eD1sOU emAWKnsgMNH2J1Ph7QGYBNOqx2i5XUlIt2kt4HrDl/ZjR8ZSTdczmkBfoScEXRIz8UpSXjWc/ NLd2Be23vz4GFUyRAgKEZ0EdeaYHF25fQcx5DlgyfyI35jllGy41Wcbq2Cpj/xZaGV7UmYiiv 5Tovde5CVqa3yzlofa5LesoJL4fuEk/7f8xtb3kmW6YUwne+Fj0+XePdP5v18GybKGLbYVwDM HzYCYw0oF8DVzWZKjcHPT4ghtKjCH6izvdJU32RJ3lDsgd1rF6m2grp5ay5DZTJxDaC28lODD TwhiNAkKa/a8/bhwfpW3Wv4RNau5Nq2TqqkYd2K+nhvGPMj7B9Afcdp24wSluOb9gzyq+xX2X CKs7Gun2l7sqwF7cmKSkVrHNBaTM/WEe97kNxavVs2wBEZhWIn1k3zcgpmiB1Rr6s9THUYEf9 +otd2qC/6ABwCU5cqUU8Bz+9xsjAWJAsAsZ2jvNOtiO/lyF9vTHDjn7ow21vz9hboQW12Hd1O /IYwYDg792Ee43VVqhCrZnukYtH1VWGG6zsz3RpDv5NUPGYW4cQCida+O1Ka31L7NVOfuMfRj z/KIxa+ftiIO8P3rStutKdVhMhbW1MV7QR2D8QFTTRveaoTZrcWq6cBK5XV/ePw8rQqE+DJgE NUdTpdMepfqEJHzFIFanUvBPLj2TH5LChq6EgmFrzOlmOzz0P8fAVvCExUkq4V7SmxlRv68iv a9GL04MeeLO/OcOYh326r9iAarncoorGkM+nRe7rv/J1uajYTkEMeRHuMdI5sbX/sYeEqa4ot XdXtEQyw2/YwgYbY2y9H3rf1qubB0T5DXM5QMbAgYZL5F1HbF6pTkKDAlI2Xo2ExUSzH5l98q 98phbQPsJ2OyBTVVIgC+wCrrrpld+KQGqkYc/IJtTIPszKGaM2AfZ8kKJs3fyKOeY7utoa+z2 K3OjcubfUlmiAb66xhlyjLuMf+5rVau72O5WYduVloXmDIAIXD/HtmfWv9XwKAsngsp0NAT+q kJFR4GQ7UeFwDydgoNGk0X+rOT6tvjqzhQhHycrAvjv8XvswaC5ghuwzYgvjvPHCfXV6T8K7f MKQMIWISY/0TlslcqS6OexWR/NYhLs6FBA8Pjujdp2l9jWVoF++o+MlBIWo29i1uioTaWXBZa QP09MOJR9rxDjzEJbsemheP/JCe8E/wDSAm0xZlCnF320CEM9GE9nXcATEwFYqccJZqY9oPF1 K5sutXXQwF X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Dmitry Gutov writes: Hi, > Last I heard, Tramp's branch wasn't stable for everyday use (citing > hangs, IIRC), but it has a set-process-thread call, locking > connection's process to thread explicitly: > > https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/lisp/net/tramp.el?h=feature/tramp-thread-safe#n2759 It's years ago, but AFAIR the knockout for me was bug#32426 (merged with bug#25214). And there are further open thread-related bugs from that time I have marked locally: bug#32487, bug#33135, bug#41220. Best regards, Michael. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 10:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Zhengyi Fu Cc: i@fuzy.me, sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17570689454620 (code B ref 79367); Fri, 05 Sep 2025 10:43:02 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 10:42:25 +0000 Received: from localhost ([127.0.0.1]:51954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuTtg-0001CR-Oh for submit@debbugs.gnu.org; Fri, 05 Sep 2025 06:42:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42180) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuTtd-0001C5-09 for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 06:42:22 -0400 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 1uuTtV-00065g-Us; Fri, 05 Sep 2025 06:42:13 -0400 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=kV3r/60ukrC3y1z7NLoyuvIwIXtPPgDamoVVg++qrM0=; b=dv4drpG4DEfK HJur8TreHGfPMsQBaowrTgHCJcf9gFf9RQlTYkq1CNmr2VoY2JfNDf8MQ/Dd7lQAssgq58VBbMvhx itMLxxTReCL0vbhabi7ODfoxlzrLcUMryPAFSWA6iKFZ8l1+Mdm2FOXBrvX7+PCrtenCn+OVakVqp WyjJS+R/M4lHRdLezlFePlujKpzlhum8Wkz8MSqfDlQqrFGl66SFxuU+RaQw9cm7A7WEqnIX3pzDF 84Rasc9BlBjv6036RjMSaOaroURzVdNq0hJx2Kf75+ZeJtRcmfG+D43odRdqpTDjgMv1OIay9aDgx 8+P5DnBDL399CCbRRHUyfA==; Date: Fri, 05 Sep 2025 13:42:09 +0300 Message-Id: <86o6rpi3jy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Zhengyi Fu on Fri, 05 Sep 2025 14:51:42 +0800) References: <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zhengyi Fu > Cc: Spencer Baugh , i@fuzy.me, > 79367@debbugs.gnu.org, dmitry@gutov.dev > Date: Fri, 05 Sep 2025 14:51:42 +0800 > > > I feel that we are splitting hair, so I went ahead and installed the > > last agreed-to version of the patch. > > I got an assertion failure when testing the latest master. What is the recipe for reproducing this? From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 11:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: i@fuzy.me, sbaugh@janestreet.com, dmitry@gutov.dev Cc: 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175707112012420 (code B ref 79367); Fri, 05 Sep 2025 11:19:01 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 11:18:40 +0000 Received: from localhost ([127.0.0.1]:52110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuUSl-0003EF-Mn for submit@debbugs.gnu.org; Fri, 05 Sep 2025 07:18:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49132) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuUSe-0003Dn-WB for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 07:18:36 -0400 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 1uuUSU-0001QK-Ps; Fri, 05 Sep 2025 07:18:22 -0400 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=Z/L5M6RREG3cKParv7WoOMjXrc989jGRsTKTDQNF41A=; b=q7jqK1s1ymhq Qby5XVzKdyhbsOEU1M5pQqo9/0hS0q0kEyMFs3YufSlMaUIO6ADRZ4ZzJQO45ebFLtQS/Sh2NAEXX DmBUI2FOGioq2VN9C831EBl3OBdY7CiZBcVX6Bn/wblUMROPxwB45xeCzZr9XctDBHrH7DJ9ZDQ1p 8JeiDzl7BYwyEUyqMlCYnQUA89k/3rvJepHHVhZ0ICYgW8eRKy26yJ5WSHTMwCLvOkdLP5kNdxApG iLoEJ/ROciqbKCCI4ptq0Zww2cri7Ies79OLCPTZumaphaJ5+q/B75awROcJHDgGD3/rZgpL0uYNR 2HU+TALpS6g9tR/6XJy3Gg==; Date: Fri, 05 Sep 2025 14:18:07 +0300 Message-Id: <86ldmti1w0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86o6rpi3jy.fsf@gnu.org> (message from Eli Zaretskii on Fri, 05 Sep 2025 13:42:09 +0300) References: <863495lz0d.fsf@gnu.org> <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: i@fuzy.me, sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Fri, 05 Sep 2025 13:42:09 +0300 > From: Eli Zaretskii > > > From: Zhengyi Fu > > Cc: Spencer Baugh , i@fuzy.me, > > 79367@debbugs.gnu.org, dmitry@gutov.dev > > Date: Fri, 05 Sep 2025 14:51:42 +0800 > > > > > I feel that we are splitting hair, so I went ahead and installed the > > > last agreed-to version of the patch. > > > > I got an assertion failure when testing the latest master. > > What is the recipe for reproducing this? Also, does the below fix the problem? diff --git a/src/process.c b/src/process.c index fa003c2..e39e02f 100644 --- a/src/process.c +++ b/src/process.c @@ -4831,7 +4831,11 @@ deactivate_process (Lisp_Object proc) /* Beware SIGCHLD hereabouts. */ for (i = 0; i < PROCESS_OPEN_FDS; i++) - close_process_fd (&p->open_fd[i]); + { + close_process_fd (&p->open_fd[i]); + fd_callback_info[p->open_fd[i]].thread = NULL; + fd_callback_info[p->open_fd[i]].waiting_thread = NULL; + } inchannel = p->infd; eassert (inchannel < FD_SETSIZE); From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 13:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: dmitry@gutov.dev, sbaugh@janestreet.com, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175707790020381 (code B ref 79367); Fri, 05 Sep 2025 13:12:02 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 13:11:40 +0000 Received: from localhost ([127.0.0.1]:53126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuWE7-0005Ia-4Q for submit@debbugs.gnu.org; Fri, 05 Sep 2025 09:11:39 -0400 Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]:36817) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuWE1-0005HU-MJ for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 09:11:35 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 2ED6C43A1C; Fri, 5 Sep 2025 13:11:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1757077887; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=O562j2cl6ehYwDXcyFBLS2wsiqIMpH2c2gOLOoliSEY=; b=bWZuKeJC5PgDgcpNJ+nXL+gDuHTt8XhMk7GDIdwGC70plqstTClhD1k+q0bUu0ovXeDedA 0wsQkzfQSBNFR3uJZdJHoR/E39rvxFf4D9+Epyucb8vA3qMViccNgaBwYVCCxhN5yli83f ZnsYAX/SYhn2GKOYooDjEy1cGNgfpBEDaVw54qxWDaqKhOPTBERVeRPE2BRWc51Pxoekwa okj3/ImupGEBxeJzVFokbZcpk8Jf4S5elI7XjWmxIoslo8d+pJk3rNadwiBTL7QVwb2Bys 0DfsGRmpCKCgzWxkvfeyCIVNWhdY1o80ocD0/HVvoM+FUqXO275K8QCds3mzPA== From: Zhengyi Fu In-Reply-To: <86o6rpi3jy.fsf@gnu.org> References: <86qzwolwxc.fsf@gnu.org> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> Date: Fri, 05 Sep 2025 21:11:22 +0800 Message-ID: <87zfb92ged.fsf@fuzy.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdekleekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfgfgggtsehttdertddtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeetvdeuveffjedugfdtjeeugfejjeegtdekteefffdtgefgffetffeiuefhtdegfeenucfkphepgeehrdekrddukeeirddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgeehrdekrddukeeirddutddvpdhhvghloheptggrlhhlihhophgvpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepgedprhgtphhtthhopegumhhithhrhiesghhuthhovhdruggvvhdprhgtphhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Zhengyi Fu >> Cc: Spencer Baugh , i@fuzy.me, >> 79367@debbugs.gnu.org, dmitry@gutov.dev >> Date: Fri, 05 Sep 2025 14:51:42 +0800 >> >> > I feel that we are splitting hair, so I went ahead and installed the >> > last agreed-to version of the patch. >> >> I got an assertion failure when testing the latest master. > > What is the recipe for reproducing this? The same steps as I described in the original bug report. It repeated the steps a few times beforing triggering the assertion failure. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 13:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175707836323671 (code B ref 79367); Fri, 05 Sep 2025 13:20:02 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 13:19:23 +0000 Received: from localhost ([127.0.0.1]:53302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuWLb-00069g-4x for submit@debbugs.gnu.org; Fri, 05 Sep 2025 09:19:23 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]:38799) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuWLT-00067i-H1 for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 09:19:19 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id A443043B42; Fri, 5 Sep 2025 13:19:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1757078348; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Js0+nFrU6KWH2Y/SHSTtTJRDcaxZ6bnwM35PAElYvFs=; b=MoeNsQk2JG5lHNTu6sLoHqSH9/y9LqrOIJvmZXQllBKZyuEBOOh0VH9aMxPSvYKInUsPyb ZeqlXTLKUhmSKKK7SzWLLQANNPkMM3RZuWGFoIwOzL4cXBKzCXdip2kIaGa4bhhy+HV5BP s85OxA/0fSIFbwi1ftJOJRxH0qNaOAuxAxSN0wf1Bi0u56Z6ARe1VAD98KyGHQztyaNTb5 1/wJIFoDv5OqcAiF9m321e1CO7A8hT5s8CWw6Y+3o+KJvIYY+ebl5T+Ac4nIYoryAi0IK5 6Az2vjY9US4zd8Lrdi3I+skMzuWlv1yEBY2G8C1BNKamUoT9lTvvn/EqQ1RbUw== From: Zhengyi Fu In-Reply-To: <86ldmti1w0.fsf@gnu.org> References: <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> Date: Fri, 05 Sep 2025 21:19:02 +0800 Message-ID: <87tt1h2g1l.fsf@fuzy.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdekleelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfgfgggtsehttdertddtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeetvdeuveffjedugfdtjeeugfejjeegtdekteefffdtgefgffetffeiuefhtdegfeenucfkphepgeehrdekrddukeeirddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgeehrdekrddukeeirddutddvpdhhvghloheptggrlhhlihhophgvpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepgedprhgtphhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepughmihhtrhihsehguhhtohhvrdguvghvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> Cc: i@fuzy.me, sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org >> Date: Fri, 05 Sep 2025 13:42:09 +0300 >> From: Eli Zaretskii >> >> > From: Zhengyi Fu >> > Cc: Spencer Baugh , i@fuzy.me, >> > 79367@debbugs.gnu.org, dmitry@gutov.dev >> > Date: Fri, 05 Sep 2025 14:51:42 +0800 >> > >> > > I feel that we are splitting hair, so I went ahead and installed the >> > > last agreed-to version of the patch. >> > >> > I got an assertion failure when testing the latest master. >> >> What is the recipe for reproducing this? > > Also, does the below fix the problem? > > diff --git a/src/process.c b/src/process.c > index fa003c2..e39e02f 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -4831,7 +4831,11 @@ deactivate_process (Lisp_Object proc) > /* Beware SIGCHLD hereabouts. */ > > for (i = 0; i < PROCESS_OPEN_FDS; i++) > - close_process_fd (&p->open_fd[i]); > + { > + close_process_fd (&p->open_fd[i]); > + fd_callback_info[p->open_fd[i]].thread = NULL; > + fd_callback_info[p->open_fd[i]].waiting_thread = NULL; > + } > > inchannel = p->infd; > eassert (inchannel < FD_SETSIZE); No. I can still reproduce this after applying the patch. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 13:27:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Zhengyi Fu Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175707879827445 (code B ref 79367); Fri, 05 Sep 2025 13:27:03 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 13:26:38 +0000 Received: from localhost ([127.0.0.1]:53454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuWSY-000784-Bu for submit@debbugs.gnu.org; Fri, 05 Sep 2025 09:26:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60004) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuWSS-00076M-3K for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 09:26:30 -0400 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 1uuWSG-0005xw-5X; Fri, 05 Sep 2025 09:26:16 -0400 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=7gHrNkZdsgfjnphejyWcCaLtxicoF1Pzkk6kEMCcmfQ=; b=TRQ+3WO7rwTi GttMOBS+7Z3nkMB8DfQNrAMMw0dfDcXZFHZY2RSQxx1A+pp/r3fyF8oiDPPoIJ3cooMZ3NhnTKVHe oYkgZ+sC+eztnH12JsLAHvCnLonz1i+P8DnGV4wHwmR5/pAqa6xT9pCPMcJAWeZxuNtzcZauOA2Hm lbhr36TfzE9i5T+LygxZZokGttvDfuGxX/jY3I+D3ldPn5OFQ16qDDAx3WJGEJaZXuACzUnuFkLtb gu2r8Lsm4pQCpEL6TsRvET8NHlGxm+DfNd8/CUZKwN5NGdcyPjUPEtYkrKZMCiHC23+THeOpZH2Uw vF6h1XMI4RxKzd9lvveNPw==; Date: Fri, 05 Sep 2025 16:26:04 +0300 Message-Id: <86frd1hvyr.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87tt1h2g1l.fsf@fuzy.me> (message from Zhengyi Fu on Fri, 05 Sep 2025 21:19:02 +0800) References: <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@gutov.dev> <86cy88ll37.fsf@gnu.org> <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> <87tt1h2g1l.fsf@fuzy.me> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zhengyi Fu > Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Fri, 05 Sep 2025 21:19:02 +0800 > > Eli Zaretskii writes: > > >> Cc: i@fuzy.me, sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > >> Date: Fri, 05 Sep 2025 13:42:09 +0300 > >> From: Eli Zaretskii > >> > >> > From: Zhengyi Fu > >> > Cc: Spencer Baugh , i@fuzy.me, > >> > 79367@debbugs.gnu.org, dmitry@gutov.dev > >> > Date: Fri, 05 Sep 2025 14:51:42 +0800 > >> > > >> > > I feel that we are splitting hair, so I went ahead and installed the > >> > > last agreed-to version of the patch. > >> > > >> > I got an assertion failure when testing the latest master. > >> > >> What is the recipe for reproducing this? > > > > Also, does the below fix the problem? > > > > diff --git a/src/process.c b/src/process.c > > index fa003c2..e39e02f 100644 > > --- a/src/process.c > > +++ b/src/process.c > > @@ -4831,7 +4831,11 @@ deactivate_process (Lisp_Object proc) > > /* Beware SIGCHLD hereabouts. */ > > > > for (i = 0; i < PROCESS_OPEN_FDS; i++) > > - close_process_fd (&p->open_fd[i]); > > + { > > + close_process_fd (&p->open_fd[i]); > > + fd_callback_info[p->open_fd[i]].thread = NULL; > > + fd_callback_info[p->open_fd[i]].waiting_thread = NULL; > > + } > > > > inchannel = p->infd; > > eassert (inchannel < FD_SETSIZE); > > No. I can still reproduce this after applying the patch. Thanks, then please show the value of the offending descriptor which causes the assertion violation. For that, please run Emacs udner GDB, perform the recipe that reproduces the problem, and then type these GDB commands: (gdb) frame 1 (gdb) print p->infd and tell what that produces. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 13:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175707939632434 (code B ref 79367); Fri, 05 Sep 2025 13:37:02 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 13:36:36 +0000 Received: from localhost ([127.0.0.1]:53578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuWcG-0008R4-5A for submit@debbugs.gnu.org; Fri, 05 Sep 2025 09:36:36 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:47517) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuWc7-0008Ps-KV for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 09:36:33 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 0177E43350; Fri, 5 Sep 2025 13:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1757079381; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bQr7Q6zbZoZOVjpZaDjr2Cve41qUtqwnGRVFRtVZTyk=; b=ZMSfJMqibMbcqX1W7OlpX4E9XoGJYdyW/Jzznb3ShsXljovFqqNhtmsIznOjvFNTgQw355 YUmRrefX35lHCH3maH4qKppOH8v2cDbHtoepF90I1YlxS/OoxJG2W8bR3yap3hTmFED9p8 jsDQjAiBcyO0fpzDfN2NrphZyYUNfvmxWrkFjnNJlUXSW7NLutXHVAv3EF8b4Qf1m4SR2l V1vzTkajn+/FMbZ4XOm+w3Ugx89ClzgayL6XdOFnP6hHHqs+FTrtyL6C9JhHGkvdVN7/yP Y4fatkDJgloehyCvVcNBBHRrco17KDmR+WvA82djetQoG+Ev4pZlGggsLsCJ8w== From: Zhengyi Fu In-Reply-To: <86frd1hvyr.fsf@gnu.org> References: <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> <87tt1h2g1l.fsf@fuzy.me> <86frd1hvyr.fsf@gnu.org> Date: Fri, 05 Sep 2025 21:36:16 +0800 Message-ID: <87plc52f8v.fsf@fuzy.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeltddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfgfgggtsehttdertddtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeetvdeuveffjedugfdtjeeugfejjeegtdekteefffdtgefgffetffeiuefhtdegfeenucfkphepgeehrdekrddukeeirddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgeehrdekrddukeeirddutddvpdhhvghloheptggrlhhlihhophgvpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepgedprhgtphhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepughmihhtrhihsehguhhtohhvrdguvghvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Zhengyi Fu >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org >> Date: Fri, 05 Sep 2025 21:19:02 +0800 >> >> Eli Zaretskii writes: >> >> >> Cc: i@fuzy.me, sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org >> >> Date: Fri, 05 Sep 2025 13:42:09 +0300 >> >> From: Eli Zaretskii >> >> >> >> > From: Zhengyi Fu >> >> > Cc: Spencer Baugh , i@fuzy.me, >> >> > 79367@debbugs.gnu.org, dmitry@gutov.dev >> >> > Date: Fri, 05 Sep 2025 14:51:42 +0800 >> >> > >> >> > > I feel that we are splitting hair, so I went ahead and installed the >> >> > > last agreed-to version of the patch. >> >> > >> >> > I got an assertion failure when testing the latest master. >> >> >> >> What is the recipe for reproducing this? >> > >> > Also, does the below fix the problem? >> > >> > diff --git a/src/process.c b/src/process.c >> > index fa003c2..e39e02f 100644 >> > --- a/src/process.c >> > +++ b/src/process.c >> > @@ -4831,7 +4831,11 @@ deactivate_process (Lisp_Object proc) >> > /* Beware SIGCHLD hereabouts. */ >> > >> > for (i = 0; i < PROCESS_OPEN_FDS; i++) >> > - close_process_fd (&p->open_fd[i]); >> > + { >> > + close_process_fd (&p->open_fd[i]); >> > + fd_callback_info[p->open_fd[i]].thread = NULL; >> > + fd_callback_info[p->open_fd[i]].waiting_thread = NULL; >> > + } >> > >> > inchannel = p->infd; >> > eassert (inchannel < FD_SETSIZE); >> >> No. I can still reproduce this after applying the patch. > > Thanks, then please show the value of the offending descriptor which > causes the assertion violation. For that, please run Emacs udner GDB, > perform the recipe that reproduces the problem, and then type these > GDB commands: > > (gdb) frame 1 > (gdb) print p->infd > > and tell what that produces. The p->infd value is 8. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 14:40:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Zhengyi Fu Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175708316930564 (code B ref 79367); Fri, 05 Sep 2025 14:40:06 +0000 Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 14:39:29 +0000 Received: from localhost ([127.0.0.1]:55187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuXb6-0007wt-PZ for submit@debbugs.gnu.org; Fri, 05 Sep 2025 10:39:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45990) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuXb2-0007w2-Fy for 79367@debbugs.gnu.org; Fri, 05 Sep 2025 10:39:26 -0400 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 1uuXas-000647-DT; Fri, 05 Sep 2025 10:39:14 -0400 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=emVCxAjdt+0crMTOeu8sZIjJoth3DvroF8ztbgisPIU=; b=fKkuk3qycoE0 duRzI3eCIS/sev/dVyQVWI77R6LOmbNSr10MGLbuKCFD3+7Im1tSRf92Kc0YQxU47TImASG+gxWtA Q76ReTDAP3T1Gl+yCNAIWmvHkDsEbPwacZuysXd7L5c/cbXkyXm6zWAZOoMcuvmXqL3LmuC77ehbm fZq0b/2+5GaRpaC7QaIkqMS9zBSnSVGGUL7O0Ok4jZShKNcC2OX4m9BU6BArejLclAH3O3v/pjcMN xFq15UZWlphwQJUkLka/aI8R7tB/HnJxF5hjVcK91xZ+VkMzjbOAOjO3OnIJSJUva8KcXQrAlsEvf /99tSFeyYMLfLwTmeYd3jA==; Date: Fri, 05 Sep 2025 17:39:10 +0300 Message-Id: <86ecslhskx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87plc52f8v.fsf@fuzy.me> (message from Zhengyi Fu on Fri, 05 Sep 2025 21:36:16 +0800) References: <86a53blqux.fsf@gnu.org> <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> <87tt1h2g1l.fsf@fuzy.me> <86frd1hvyr.fsf@gnu.org> <87plc52f8v.fsf@fuzy.me> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zhengyi Fu > Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Fri, 05 Sep 2025 21:36:16 +0800 > > Eli Zaretskii writes: > > > Thanks, then please show the value of the offending descriptor which > > causes the assertion violation. For that, please run Emacs udner GDB, > > perform the recipe that reproduces the problem, and then type these > > GDB commands: > > > > (gdb) frame 1 > > (gdb) print p->infd > > > > and tell what that produces. > > The p->infd value is 8. OK, please repeat this several times to make sure it's always 8. If it is, then let's try to see which code leaves the .thread field uncleared. Like this (please run from the src directory where you have the 'emacs' executable you have built): $ gdb ./emacs ... (gdb) break process.c:8731 (gdb) run Emacs will start and stop in init_process_emacs, on line 8731 of process.c. Then: (gdb) watch fd_callback_info[8].thread (gdb) commands > bt 5 > continue > end (gdb) continue The above sets a watchpoint which will stop Emacs each time we assign some value to fd_callback_info[8].thread, and GDB will then show the first 5 frames of the call-stack, then continue. Now run your recipe, until it gets SIGABRT, and post everything GDB produced until that point. I hope that will tell us which code fails to clear the .thread member. Thanks. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 05:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175713697532524 (code B ref 79367); Sat, 06 Sep 2025 05:37:02 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 05:36:15 +0000 Received: from localhost ([127.0.0.1]:60538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uulav-0008SP-D4 for submit@debbugs.gnu.org; Sat, 06 Sep 2025 01:36:15 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]:52761) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uulan-0008Qn-1s for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 01:36:09 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 2777F443BB; Sat, 6 Sep 2025 05:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1757136956; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qojfY+UHuVrE8hSDljWtpIKPpyLqQGuOmQHabMD71lI=; b=hlf4+eJ/4AgCHgshP8vlDforteS6/AeMATUWn+aYsZGN8H4myUZJAqpRVCiFidxMFOkXTj i6jIGY9pzJKy0lNnB5dkiBumfaOp2OHbStpgVXXZTUkSne4ipdGjdx6WHlaOtPrwlqtAvU deD7FngY4bd5vhYmqp4NrbwSz5h2xAf3bNSvUaBG0R/QEiW13Q8rJlqDakJk5JDsfcc94W Imrgw18oyYknO0XsHzUbeZeCv706bco6oXi/wpjBLvddtOoEbRtvMIC7JSf1M7bfe1EzLi 4oR1F2i9tVFn4AUc2YEPmKUWRdEOQ0HDgTvsGF3a2Ck3goMyHcy3AiwBoBIepQ== From: Zhengyi Fu In-Reply-To: <86ecslhskx.fsf@gnu.org> References: <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> <87tt1h2g1l.fsf@fuzy.me> <86frd1hvyr.fsf@gnu.org> <87plc52f8v.fsf@fuzy.me> <86ecslhskx.fsf@gnu.org> Date: Sat, 06 Sep 2025 13:35:49 +0800 Message-ID: <87v7lww3be.fsf@fuzy.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddutdelgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghffffkfgggtgfgsehtqhertddtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeeiiedukefgkeeiueegvdetgfeiffetuefgjeeuudeuvefhheeuveeiheegfeelheenucffohhmrghinhepghhnuhdrohhrghenucfkphepudduvddrieehrdduvddrvdegfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduuddvrdeihedruddvrddvgeefpdhhvghloheptggrlhhlihhophgvpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepgedprhgtphhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepughmihhtrhihsehguhhtohhvrdguvghvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Zhengyi Fu >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org >> Date: Fri, 05 Sep 2025 21:36:16 +0800 >>=20 >> Eli Zaretskii writes: >>=20 >> > Thanks, then please show the value of the offending descriptor which >> > causes the assertion violation. For that, please run Emacs udner GDB, >> > perform the recipe that reproduces the problem, and then type these >> > GDB commands: >> > >> > (gdb) frame 1 >> > (gdb) print p->infd >> > >> > and tell what that produces. >>=20 >> The p->infd value is 8. > > OK, please repeat this several times to make sure it's always 8. > > If it is, then let's try to see which code leaves the .thread field > uncleared. Like this (please run from the src directory where you > have the 'emacs' executable you have built): > > $ gdb ./emacs > ... > (gdb) break process.c:8731 > (gdb) run > > Emacs will start and stop in init_process_emacs, on line 8731 of > process.c. Then: > > (gdb) watch fd_callback_info[8].thread > (gdb) commands > > bt 5 > > continue > > end > (gdb) continue > > The above sets a watchpoint which will stop Emacs each time we assign > some value to fd_callback_info[8].thread, and GDB will then show the > first 5 frames of the call-stack, then continue. Now run your recipe, > until it gets SIGABRT, and post everything GDB produced until that > point. I hope that will tell us which code fails to clear the .thread > member. > > Thanks. The fd is 8 when running Emacs in terminal. The fd is always 16 when running Emacs in X11. GNU gdb (Fedora Linux) 16.3-1.fc42 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./emacs... SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from te= rminal] DISPLAY =3D :0.0 TERM =3D foot Breakpoint 1 at 0x556a1d: file emacs.c, line 442. Breakpoint 2 at 0x5211c6: file xterm.c, line 27074. Breakpoint 3 at 0x600880: file eval.c, line 3108. (gdb) break process.c:8731 Breakpoint 4 at 0x6610d8: file process.c, line 8732. (gdb) run Starting program: /home/zhengyi/src/emacs_master/src/emacs -Q -l /home/zhen= gyi/.config/emacs/straight/repos/straight.el/bootstrap.el --eval ' '\(progn\ ' '\(straight-use-package\ \'diff-hl\)' '\(straight-use-package\ \'magit\)' '\(setq\ diff-hl-update-async\ t\)' '\(global-diff-hl-mode\)' '\) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 4, init_process_emacs (sockfd=3Dsockfd@entry=3D-1) at process.c:= 8732 8732 num_pending_connects =3D 0; Missing rpms, try: dnf --enablerepo=3D'*debug*' install gtk3-debuginfo-3.24= .49-2.fc42.x86_64 zlib-ng-compat-debuginfo-2.2.5-2.fc42.x86_64 pango-debugi= nfo-1.56.4-1.fc42.x86_64 harfbuzz-debuginfo-10.4.0-1.fc42.x86_64 atk-debugi= nfo-2.56.3-1.fc42.x86_64 cairo-gobject-debuginfo-1.18.2-3.fc42.x86_64 cairo= -debuginfo-1.18.2-3.fc42.x86_64 gdk-pixbuf2-debuginfo-2.42.12-12.fc42.x86_6= 4 glib2-debuginfo-2.84.4-1.fc42.x86_64 libX11-debuginfo-1.8.12-1.fc42.x86_6= 4 libX11-xcb-debuginfo-1.8.12-1.fc42.x86_64 libxcb-debuginfo-1.17.0-5.fc42.= x86_64 libXrandr-debuginfo-1.5.4-5.fc42.x86_64 libXinerama-debuginfo-1.1.5-= 8.fc42.x86_64 libXfixes-debuginfo-6.0.1-5.fc42.x86_64 libXext-debuginfo-1.3= .6-3.fc42.x86_64 ncurses-libs-debuginfo-6.5-5.20250125.fc42.x86_64 glibc-de= buginfo-2.41-11.fc42.x86_64 gmp-debuginfo-6.3.0-4.fc42.x86_64 libXcomposite= -debuginfo-0.4.6-5.fc42.x86_64 fontconfig-debuginfo-2.16.0-2.fc42.x86_64 fr= ibidi-debuginfo-1.0.16-2.fc42.x86_64 libepoxy-debuginfo-1.5.10-9.fc42.x86_6= 4 libXi-debuginfo-1.8.2-2.fc42.x86_64 at-spi2-atk-debuginfo-2.56.3-1.fc42.x= 86_64 libcloudproviders-debuginfo-0.3.6-1.fc42.x86_64 libtinysparql-debugin= fo-3.9.2-1.fc42.x86_64 libwayland-client-debuginfo-1.24.0-1.fc42.x86_64 lib= xkbcommon-debuginfo-1.8.1-1.fc42.x86_64 libwayland-cursor-debuginfo-1.24.0-= 1.fc42.x86_64 libwayland-egl-debuginfo-1.24.0-1.fc42.x86_64 libXcursor-debu= ginfo-1.2.3-2.fc42.x86_64 libXdamage-debuginfo-1.1.6-5.fc42.x86_64 libthai-= debuginfo-0.1.29-10.fc42.x86_64 freetype-debuginfo-2.13.3-2.fc42.x86_64 gra= phite2-debuginfo-1.3.14-18.fc42.x86_64 libpng-debuginfo-1.6.44-2.fc42.x86_6= 4 libXrender-debuginfo-0.9.12-2.fc42.x86_64 pixman-debuginfo-0.46.2-1.fc42.= x86_64 libjpeg-turbo-debuginfo-3.1.0-2.fc42.x86_64 libmount-debuginfo-2.40.= 4-7.fc42.x86_64 libselinux-debuginfo-3.8-2.fc42.x86_64 libffi-debuginfo-3.4= .6-5.fc42.x86_64 pcre2-debuginfo-10.45-1.fc42.x86_64 libXau-debuginfo-1.0.1= 2-2.fc42.x86_64 libxml2-debuginfo-2.12.10-1.fc42.x86_64 at-spi2-core-debugi= nfo-2.56.3-1.fc42.x86_64 dbus-libs-debuginfo-1.16.0-3.fc42.x86_64 libgcc-de= buginfo-15.2.1-1.fc42.x86_64 json-glib-debuginfo-1.10.6-2.fc42.x86_64 sqlit= e-libs-debuginfo-3.47.2-2.fc42.x86_64 libdatrie-debuginfo-0.2.13-11.fc42.x8= 6_64 bzip2-libs-debuginfo-1.0.8-20.fc42.x86_64 libbrotli-debuginfo-1.1.0-6.= fc42.x86_64 libblkid-debuginfo-2.40.4-7.fc42.x86_64 xz-libs-debuginfo-5.8.1= -2.fc42.x86_64 systemd-libs-debuginfo-257.7-1.fc42.x86_64 libcap-debuginfo-= 2.73-2.fc42.x86_64 (gdb) watch fd_callback_info[16].thread Hardware watchpoint 5: fd_callback_info[16].thread (gdb) commands Type commands for breakpoint(s) 5, one per line. End with a line saying just "end". >bt 5 >continue >end (gdb) continue Continuing. [New Thread 0x7fffe6bfe6c0 (LWP 741835)] [New Thread 0x7fffe63fd6c0 (LWP 741836)] [New Thread 0x7fffe5bfc6c0 (LWP 741837)] [New Thread 0x7fffe4fff6c0 (LWP 741838)] [New Thread 0x7fffd7fff6c0 (LWP 741839)] [New Thread 0x7fffd77fe6c0 (LWP 741840)] [Detaching after vfork from child process 741841] [Detaching after vfork from child process 741842] [Detaching after vfork from child process 741843] [Detaching after vfork from child process 741845] [Detaching after vfork from child process 741846] [Detaching after vfork from child process 741847] [Detaching after vfork from child process 741848] [Detaching after vfork from child process 741849] [Detaching after vfork from child process 741850] [Detaching after vfork from child process 741851] [Detaching after vfork from child process 741852] [Detaching after vfork from child process 741853] [Detaching after vfork from child process 741854] [Detaching after vfork from child process 741865] [Detaching after vfork from child process 741866] [Detaching after vfork from child process 741867] [Detaching after vfork from child process 741868] [Detaching after vfork from child process 741869] [Detaching after vfork from child process 741870] [Detaching after vfork from child process 741871] [Detaching after vfork from child process 741872] [Detaching after vfork from child process 741873] [Detaching after vfork from child process 741874] [Detaching after vfork from child process 741885] [Detaching after vfork from child process 741896] [Detaching after vfork from child process 741897] [Detaching after vfork from child process 741898] [Detaching after vfork from child process 741899] [Detaching after vfork from child process 741900] [Detaching after vfork from child process 741901] [Detaching after vfork from child process 741902] [Detaching after vfork from child process 741903] [Detaching after vfork from child process 741904] [Detaching after vfork from child process 741905] [Detaching after vfork from child process 741906] [Detaching after vfork from child process 741907] [Detaching after vfork from child process 741908] [Detaching after vfork from child process 741909] [Detaching after vfork from child process 741910] [Detaching after vfork from child process 741911] [Detaching after vfork from child process 741912] [Detaching after vfork from child process 741913] [Detaching after vfork from child process 741914] [Detaching after vfork from child process 741915] [Detaching after vfork from child process 741916] [Detaching after vfork from child process 741917] [Detaching after vfork from child process 741918] [Detaching after vfork from child process 741919] [Detaching after vfork from child process 741920] [Detaching after vfork from child process 741921] [Detaching after vfork from child process 741922] [Detaching after vfork from child process 741923] [Detaching after vfork from child process 741924] [Detaching after vfork from child process 741925] [Detaching after vfork from child process 741926] [Detaching after vfork from child process 741927] [Detaching after vfork from child process 741928] [Detaching after vfork from child process 741929] [Detaching after vfork from child process 741930] Thread 1 "emacs" hit Hardware watchpoint 5: fd_callback_info[16].thread Old value =3D (struct thread_state *) 0x0 New value =3D (struct thread_state *) 0x74dba0 set_proc_thread (proc=3Dproc@entry=3D0x1eef868, thrd=3D0x74dba0 ) at process.c:1457 1457 eassert (proc->outfd < FD_SETSIZE); #0 set_proc_thread (proc=3Dproc@entry=3D0x1eef868, thrd=3D0x74dba0 ) at process.c:1457 #1 0x000000000065e232 in server_accept_connection (server=3D, channel=3D) at process.c:5134 #2 wait_reading_process_output (time_limit=3Dtime_limit@entry=3D30, nsecs=3Dnsecs@entry=3D0, read_kbd= =3Dread_kbd@entry=3D-1, do_display=3Ddo_display@entry=3Dtrue, wait_for_cell= =3Dwait_for_cell@entry=3D0x0, wait_proc=3Dwait_proc@entry=3D0x0, just_wait_= proc=3D0) at process.c:5990 #3 0x000000000041217a in sit_for (timeout=3D, reading=3Dreading@entry=3Dtrue, display_opt= ion=3Ddisplay_option@entry=3D1) at dispnew.c:6978 #4 0x000000000056b4cb in read_char (commandflag=3D1, map=3Dmap@entry=3D0x1ed2c83, prev_event=3D0x0, used_m= ouse_menu=3Dused_mouse_menu@entry=3D0x7fffffffd62b, end_time=3Dend_time@ent= ry=3D0x0) at keyboard.c:2925 [Detaching after vfork from child process 741972] [Detaching after vfork from child process 741973] [Detaching after vfork from child process 741974] [Detaching after vfork from child process 741975] [Detaching after vfork from child process 741976] [Detaching after vfork from child process 741977] [Detaching after vfork from child process 741978] [Detaching after vfork from child process 741979] [Detaching after vfork from child process 741980] [Detaching after vfork from child process 741981] [Detaching after vfork from child process 741982] [Detaching after vfork from child process 741983] [Detaching after vfork from child process 741984] [Detaching after vfork from child process 741985] [Detaching after vfork from child process 741986] [Detaching after vfork from child process 741987] [Detaching after vfork from child process 741988] [Detaching after vfork from child process 741989] [Detaching after vfork from child process 741990] [Detaching after vfork from child process 741991] [Detaching after vfork from child process 741992] [Detaching after vfork from child process 741993] [Detaching after vfork from child process 741994] [Detaching after vfork from child process 741995] [Detaching after vfork from child process 741996] [Detaching after vfork from child process 741997] [Detaching after vfork from child process 741998] [Detaching after vfork from child process 741999] [Detaching after vfork from child process 742000] [Detaching after vfork from child process 742001] [Detaching after vfork from child process 742002] [Detaching after vfork from child process 742003] [Detaching after vfork from child process 742004] [Detaching after vfork from child process 742005] [Detaching after vfork from child process 742006] [Detaching after vfork from child process 742007] [Detaching after vfork from child process 742008] [Detaching after vfork from child process 742009] [Detaching after vfork from child process 742020] [Detaching after vfork from child process 742021] [Detaching after vfork from child process 742022] [Detaching after vfork from child process 742023] [Detaching after vfork from child process 742024] [Detaching after vfork from child process 742025] [Detaching after vfork from child process 742026] [Detaching after vfork from child process 742027] [Detaching after vfork from child process 742028] [Detaching after vfork from child process 742029] [Detaching after vfork from child process 742030] [Detaching after vfork from child process 742031] [Detaching after vfork from child process 742032] [New Thread 0x7fffc9fff6c0 (LWP 742033)] [Thread 0x7fffc9fff6c0 (LWP 742033) exited] Thread 1 "emacs" hit Hardware watchpoint 5: fd_callback_info[16].thread Old value =3D (struct thread_state *) 0x74dba0 New value =3D (struct thread_state *) 0x0 clear_fd_callback_data (elem=3D0x7ec320 ) at process.= c:476 476 elem->waiting_thread =3D NULL; #0 clear_fd_callback_data (elem=3D0x7ec320 ) at proc= ess.c:476 #1 delete_keyboard_wait_descriptor (desc=3Ddesc@entry=3D16) at process.c:8= 341 #2 0x0000000000657ad1 in delete_read_fd (fd=3D16) at process.c:519 #3 deactivate_process (proc=3Dproc@entry=3D0x1eef86d) at process.c:4852 #4 0x0000000000657b4a in remove_process (proc=3Dproc@entry=3D0x1eef86d) at= process.c:965 Lisp Backtrace: "delete-process" (0xe6bff1a0) "with-editor-return" (0xe6bff120) "with-editor-cancel" (0xffffd320) "funcall-interactively" (0xffffd318) "call-interactively" (0xe6bff070) "command-execute" (0xffffd838) [Detaching after vfork from child process 742034] [Detaching after vfork from child process 742035] [Detaching after vfork from child process 742036] [Detaching after vfork from child process 742037] [Detaching after vfork from child process 742038] [Detaching after vfork from child process 742039] [Detaching after vfork from child process 742040] [Detaching after vfork from child process 742041] [Detaching after vfork from child process 742042] [Detaching after vfork from child process 742043] [Detaching after vfork from child process 742054] [Detaching after vfork from child process 742055] [Detaching after vfork from child process 742056] [Detaching after vfork from child process 742057] [Detaching after vfork from child process 742058] [Detaching after vfork from child process 742059] [Detaching after vfork from child process 742060] [Detaching after vfork from child process 742061] [Detaching after vfork from child process 742062] [Detaching after vfork from child process 742063] [Detaching after vfork from child process 742064] [Detaching after vfork from child process 742065] [Detaching after vfork from child process 742076] [Detaching after vfork from child process 742087] [Detaching after vfork from child process 742088] [Detaching after vfork from child process 742089] [Detaching after vfork from child process 742090] [Detaching after vfork from child process 742091] [Detaching after vfork from child process 742092] [Detaching after vfork from child process 742093] [Detaching after vfork from child process 742094] [Detaching after vfork from child process 742095] [Detaching after vfork from child process 742096] [Detaching after vfork from child process 742097] [Detaching after vfork from child process 742098] [Detaching after vfork from child process 742099] [Detaching after vfork from child process 742100] [Detaching after vfork from child process 742101] [Detaching after vfork from child process 742102] [Thread 0x7fffd7fff6c0 (LWP 741839) exited] [Thread 0x7fffe4fff6c0 (LWP 741838) exited] [Detaching after vfork from child process 742103] [Detaching after vfork from child process 742104] [Detaching after vfork from child process 742105] [Detaching after vfork from child process 742106] [Detaching after vfork from child process 742107] [Detaching after vfork from child process 742108] [Detaching after vfork from child process 742109] [Detaching after vfork from child process 742110] [Detaching after vfork from child process 742111] [Detaching after vfork from child process 742112] [Detaching after vfork from child process 742113] [Detaching after vfork from child process 742114] [Detaching after vfork from child process 742115] [Detaching after vfork from child process 742126] [Detaching after vfork from child process 742127] [New Thread 0x7fffd7fff6c0 (LWP 742128)] [Detaching after vfork from child process 742129] [Switching to Thread 0x7fffd7fff6c0 (LWP 742128)] Thread 9 "diff-hl--update" hit Hardware watchpoint 5: fd_callback_info[16].= thread Old value =3D (struct thread_state *) 0x0 New value =3D (struct thread_state *) 0x1321ae0 0x0000000000651f83 in set_proc_thread (proc=3Dproc@entry=3D0x1b83050, thrd= =3D0x1321ae0) at process.c:1460 1460 } #0 0x0000000000651f83 in set_proc_thread (proc=3Dproc@entry=3D0x1b83050, t= hrd=3D0x1321ae0) at process.c:1460 #1 0x0000000000659a8e in create_process (process=3D0x1b83055, new_argv=3D0x7fffd7ffcdd0, current_dir=3D0x1f29a9= 4) at process.c:2272 #2 Fmake_process (nargs=3D, args=3D) at proc= ess.c:2090 #3 0x0000000000606144 in funcall_subr (subr=3D, numargs=3Dnumargs@entry=3D6, args=3Dargs@entry= =3D0x7fffd7ffd088) at eval.c:3265 #4 0x0000000000608801 in funcall_general (fun=3D, numargs=3Dnumargs@entry=3D6, args=3Dargs@entry= =3D0x7fffd7ffd088) at eval.c:3121 Lisp Backtrace: 0x761740 PVEC_SUBR "apply" (0x1faad78) "make-process@with-editor-process-filter" (0xd7ffd308) "apply" (0x1faacd0) "make-process" (0xd7ffd598) "apply" (0x1faac70) "start-process" (0xd7ffd818) "apply" (0x1faabf8) 0xf525cd80 PVEC_CLOSURE "apply" (0x1faab80) "start-file-process@with-editor-process-filter" (0xd7ffdd78) "apply" (0x1faab18) "start-file-process" (0xd7ffe028) "apply" (0x1faaab8) "vc-do-command" (0xd7ffe2d8) "apply" (0x1faa9e0) "vc-git-command" (0xd7ffe588) "apply" (0x1faa930) "vc-git-diff" (0xd7ffe828) "apply" (0x1faa8a0) "vc-call-backend" (0x1faa810) "diff-hl-diff-against-reference" (0x1faa7a8) "diff-hl-changes-buffer" (0x1faa760) "diff-hl-changes" (0x1faa6b0) "diff-hl--update" (0x1faa668) "diff-hl--update-safe" (0x1faa638) 0x1f51d38 PVEC_CLOSURE [Detaching after vfork from child process 742130] [Thread 0x7fffd7fff6c0 (LWP 742128) exited] [Detaching after vfork from child process 742141] [Detaching after vfork from child process 742142] [Detaching after vfork from child process 742143] [Detaching after vfork from child process 742144] [Detaching after vfork from child process 742145] [Detaching after vfork from child process 742146] [Detaching after vfork from child process 742147] [Detaching after vfork from child process 742148] [Detaching after vfork from child process 742149] [Detaching after vfork from child process 742150] [Detaching after vfork from child process 742151] [Detaching after vfork from child process 742152] [Detaching after vfork from child process 742153] [Detaching after vfork from child process 742154] [Detaching after vfork from child process 742155] [Detaching after vfork from child process 742156] [Detaching after vfork from child process 742157] [Detaching after vfork from child process 742158] [Detaching after vfork from child process 742159] [Detaching after vfork from child process 742160] [Detaching after vfork from child process 742161] process.c:5128: Emacs fatal error: assertion failed: !fd_callback_info[p->i= nfd].thread [Switching to Thread 0x7ffff5d91ac0 (LWP 741828)] Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=3Dsig@entry= =3D6,=20 backtrace_limit=3Dbacktrace_limit@entry=3D2147483647) at emacs.c:442 442 { Missing rpms, try: dnf --enablerepo=3D'*debug*' install gvfs-client-debugin= fo-1.57.2-1.fc42.x86_64 fcitx5-gtk3-debuginfo-5.1.4-1.fc42.x86_64 fcitx5-gt= k-debuginfo-5.1.4-1.fc42.x86_64 libstdc++-debuginfo-15.2.1-1.fc42.x86_64 rs= vg-pixbuf-loader-debuginfo-2.60.0-2.fc42.x86_64 librsvg2-debuginfo-2.60.0-2= .fc42.x86_64 libdav1d-debuginfo-1.5.1-1.fc42.x86_64 gdk-pixbuf2-modules-ext= ra-debuginfo-2.42.12-3.fc42.x86_64 (gdb)=20 From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 07:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Zhengyi Fu Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175714369212384 (code B ref 79367); Sat, 06 Sep 2025 07:29:01 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 07:28:12 +0000 Received: from localhost ([127.0.0.1]:33376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uunLH-0003Df-OV for submit@debbugs.gnu.org; Sat, 06 Sep 2025 03:28:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44960) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uunLD-0003CV-A7 for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 03:28:08 -0400 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 1uunL3-0007C8-Ui; Sat, 06 Sep 2025 03:27:57 -0400 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=4G/4qe/l28WLGzHz5wemwxVTMVQQDUJCaBzcxW0qFes=; b=QE3bsDQYx2vP eY98jzGe1iCKmPcsTb0nnbDooTvzvIEFRxqxLbHZZRhSDuJ1CFly5yZubEN4JyB//yowSY/Yrs7kM V3vHYmuEJ0d04n31NRMFFAMz+DBrNJSvJlfceQp8d0ptfkjN9wFyBplaOnbVhK/AawZBPhergWksa rU1q9N+USJ09NKfzV2GiGgSs558q74rgqxjU0Iaptx8s564Uue+je6hrG4LdyC4BzxD5Jiu14gxpJ goWAAeT+tMTtRvkzPJ2sApQYtWCk+CDO9lqinjQMsWp/BRosrDpEOs0BYCU9OK+l5/usEmgk3VqGu 2BoI35E4hNcjuYj+M6jHfA==; Date: Sat, 06 Sep 2025 10:27:51 +0300 Message-Id: <86seh0ghvs.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87v7lww3be.fsf@fuzy.me> (message from Zhengyi Fu on Sat, 06 Sep 2025 13:35:49 +0800) References: <86seh3k4ix.fsf@gnu.org> <87ecsny4vh.fsf@fuzy.me> <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> <87tt1h2g1l.fsf@fuzy.me> <86frd1hvyr.fsf@gnu.org> <87plc52f8v.fsf@fuzy.me> <86ecslhskx.fsf@gnu.org> <87v7lww3be.fsf@fuzy.me> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zhengyi Fu > Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Sat, 06 Sep 2025 13:35:49 +0800 > > Eli Zaretskii writes: > > >> From: Zhengyi Fu > >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > >> Date: Fri, 05 Sep 2025 21:36:16 +0800 > >> > >> Eli Zaretskii writes: > >> > >> > Thanks, then please show the value of the offending descriptor which > >> > causes the assertion violation. For that, please run Emacs udner GDB, > >> > perform the recipe that reproduces the problem, and then type these > >> > GDB commands: > >> > > >> > (gdb) frame 1 > >> > (gdb) print p->infd > >> > > >> > and tell what that produces. > >> > >> The p->infd value is 8. > > > > OK, please repeat this several times to make sure it's always 8. > > > > If it is, then let's try to see which code leaves the .thread field > > uncleared. Like this (please run from the src directory where you > > have the 'emacs' executable you have built): > > > > $ gdb ./emacs > > ... > > (gdb) break process.c:8731 > > (gdb) run > > > > Emacs will start and stop in init_process_emacs, on line 8731 of > > process.c. Then: > > > > (gdb) watch fd_callback_info[8].thread > > (gdb) commands > > > bt 5 > > > continue > > > end > > (gdb) continue > > > > The above sets a watchpoint which will stop Emacs each time we assign > > some value to fd_callback_info[8].thread, and GDB will then show the > > first 5 frames of the call-stack, then continue. Now run your recipe, > > until it gets SIGABRT, and post everything GDB produced until that > > point. I hope that will tell us which code fails to clear the .thread > > member. > > > > Thanks. > > The fd is 8 when running Emacs in terminal. > The fd is always 16 when running Emacs in X11. Thanks, please try the patch below, instead of the incorrect one I asked you to try before: diff --git a/src/process.c b/src/process.c index fa003c2..736098f 100644 --- a/src/process.c +++ b/src/process.c @@ -4831,7 +4831,11 @@ deactivate_process (Lisp_Object proc) /* Beware SIGCHLD hereabouts. */ for (i = 0; i < PROCESS_OPEN_FDS; i++) - close_process_fd (&p->open_fd[i]); + { + fd_callback_info[p->open_fd[i]].thread = NULL; + fd_callback_info[p->open_fd[i]].waiting_thread = NULL; + close_process_fd (&p->open_fd[i]); + } inchannel = p->infd; eassert (inchannel < FD_SETSIZE); From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 08:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175714733710411 (code B ref 79367); Sat, 06 Sep 2025 08:29:01 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 08:28:57 +0000 Received: from localhost ([127.0.0.1]:34102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuoI4-0002hr-Os for submit@debbugs.gnu.org; Sat, 06 Sep 2025 04:28:57 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:43487) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuoI0-0002hS-HK for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 04:28:54 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 8F2091F736; Sat, 6 Sep 2025 08:28:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1757147325; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hbQJRj2yK4cCttOmDiuyvq5w5CAlyaYRu+EzbkSA0EQ=; b=Gp7FZSEtfjzB8byE9/EysyshUDkz7wWEoz7uyBVoFXG6H2d5TbJh5dfPDMmnJ5khacH59X HwcQq6qAI8iY5xWxkhtq3GTJamZlJ6QNZ7TyQe1fyQtRhyT5mYqlIbJS6S0WUH54mNPMcU 0aQzYYWp0xwKpoZ07QYGtUpslWEpJsGGdTwSGzabd6TiwKHFHkcPUnaIkWqA8+wKhrUwbx 7badkRUv+3BNvhv0EoRaRpQW9hdbnyxiQ4Ix3PevNHe40mILO4diqB+TxEDs+xUmd91MiJ Pgcuw9af2PxN6XpXaAB4WXU4wS0Jzvz5PCBBeupcVDA37aa2q7EmrOOQ/g5khw== From: Zhengyi Fu In-Reply-To: <86seh0ghvs.fsf@gnu.org> References: <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> <87tt1h2g1l.fsf@fuzy.me> <86frd1hvyr.fsf@gnu.org> <87plc52f8v.fsf@fuzy.me> <86ecslhskx.fsf@gnu.org> <87v7lww3be.fsf@fuzy.me> <86seh0ghvs.fsf@gnu.org> Date: Sat, 06 Sep 2025 16:28:40 +0800 Message-ID: <87frd00ytj.fsf@fuzy.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduuddvlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghffffkfgggtgesthdtredttdertdenucfhrhhomhepkghhvghnghihihcuhfhuuceoihesfhhuiiihrdhmvgeqnecuggftrfgrthhtvghrnheptedvueevffejudfgtdejuefgjeejgedtkeetfefftdeggfffteffieeuhfdtgeefnecukfhppeeghedrkedrudekiedruddtvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeghedrkedrudekiedruddtvddphhgvlhhopegtrghllhhiohhpvgdpmhgrihhlfhhrohhmpehisehfuhiihidrmhgvpdhnsggprhgtphhtthhopeegpdhrtghpthhtohepjeelfeeijeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopegumhhithhrhiesghhuthhovhdruggvvhdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhg X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Zhengyi Fu >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org >> Date: Sat, 06 Sep 2025 13:35:49 +0800 >> >> Eli Zaretskii writes: >> >> >> From: Zhengyi Fu >> >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org >> >> Date: Fri, 05 Sep 2025 21:36:16 +0800 >> >> >> >> Eli Zaretskii writes: >> >> >> >> > Thanks, then please show the value of the offending descriptor which >> >> > causes the assertion violation. For that, please run Emacs udner GDB, >> >> > perform the recipe that reproduces the problem, and then type these >> >> > GDB commands: >> >> > >> >> > (gdb) frame 1 >> >> > (gdb) print p->infd >> >> > >> >> > and tell what that produces. >> >> >> >> The p->infd value is 8. >> > >> > OK, please repeat this several times to make sure it's always 8. >> > >> > If it is, then let's try to see which code leaves the .thread field >> > uncleared. Like this (please run from the src directory where you >> > have the 'emacs' executable you have built): >> > >> > $ gdb ./emacs >> > ... >> > (gdb) break process.c:8731 >> > (gdb) run >> > >> > Emacs will start and stop in init_process_emacs, on line 8731 of >> > process.c. Then: >> > >> > (gdb) watch fd_callback_info[8].thread >> > (gdb) commands >> > > bt 5 >> > > continue >> > > end >> > (gdb) continue >> > >> > The above sets a watchpoint which will stop Emacs each time we assign >> > some value to fd_callback_info[8].thread, and GDB will then show the >> > first 5 frames of the call-stack, then continue. Now run your recipe, >> > until it gets SIGABRT, and post everything GDB produced until that >> > point. I hope that will tell us which code fails to clear the .thread >> > member. >> > >> > Thanks. >> >> The fd is 8 when running Emacs in terminal. >> The fd is always 16 when running Emacs in X11. > > Thanks, please try the patch below, instead of the incorrect one I > asked you to try before: > > diff --git a/src/process.c b/src/process.c > index fa003c2..736098f 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -4831,7 +4831,11 @@ deactivate_process (Lisp_Object proc) > /* Beware SIGCHLD hereabouts. */ > > for (i = 0; i < PROCESS_OPEN_FDS; i++) > - close_process_fd (&p->open_fd[i]); > + { > + fd_callback_info[p->open_fd[i]].thread = NULL; > + fd_callback_info[p->open_fd[i]].waiting_thread = NULL; > + close_process_fd (&p->open_fd[i]); > + } > > inchannel = p->infd; > eassert (inchannel < FD_SETSIZE); This resolves the problem. The assertion failure no longer occurs when testing with the patch. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 09:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Zhengyi Fu Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17571518865819 (code B ref 79367); Sat, 06 Sep 2025 09:45:02 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 09:44:46 +0000 Received: from localhost ([127.0.0.1]:34487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uupTR-0001Vm-Dt for submit@debbugs.gnu.org; Sat, 06 Sep 2025 05:44:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53784) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uupTO-0001VU-G5 for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 05:44:43 -0400 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 1uupTE-0001mx-FF; Sat, 06 Sep 2025 05:44:32 -0400 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=kdkhGf47QvVClsxphnCk7uHSWQX73xhfvmDqgGsoJEY=; b=XqBwn3AQvkH5 C0gryje0Qdrbi0xhUvtC/maQpLgg/Yzs+zKDm6piaZBC9f/30MzqAO9HhZ+1tJJmgKiYsZz9Zs9q4 0qtOjecU93VLlrF2eYkkT5HMC+tENt3fWVsLq+Obkh89cuRIIDqekPMrzPvpGZLDFmb2GuuijzTao 32zjBEpR40nosVMea1I9TF3UWTwFz31mo+YDkzQ0MDYqtVpoEYSFz41USf77uI4Z5DCLd6BVQWBSp BzIxZVsA6lte/SEZxvppaOHgAx41ycqkqxUmCiTSFSDWSilGuPGflFjbeYOqokxcmQeTXtUg5nYj8 DUMIdYNs+mu94I8dhlP+HA==; Date: Sat, 06 Sep 2025 12:44:29 +0300 Message-Id: <86ms77gbk2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87frd00ytj.fsf@fuzy.me> (message from Zhengyi Fu on Sat, 06 Sep 2025 16:28:40 +0800) References: <86plc7k2oy.fsf@gnu.org> <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> <87tt1h2g1l.fsf@fuzy.me> <86frd1hvyr.fsf@gnu.org> <87plc52f8v.fsf@fuzy.me> <86ecslhskx.fsf@gnu.org> <87v7lww3be.fsf@fuzy.me> <86seh0ghvs.fsf@gnu.org> <87frd00ytj.fsf@fuzy.me> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zhengyi Fu > Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Sat, 06 Sep 2025 16:28:40 +0800 > > Eli Zaretskii writes: > > >> From: Zhengyi Fu > >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > >> Date: Sat, 06 Sep 2025 13:35:49 +0800 > >> > >> Eli Zaretskii writes: > >> > >> >> From: Zhengyi Fu > >> >> Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > >> >> Date: Fri, 05 Sep 2025 21:36:16 +0800 > >> >> > >> >> Eli Zaretskii writes: > >> >> > >> >> > Thanks, then please show the value of the offending descriptor which > >> >> > causes the assertion violation. For that, please run Emacs udner GDB, > >> >> > perform the recipe that reproduces the problem, and then type these > >> >> > GDB commands: > >> >> > > >> >> > (gdb) frame 1 > >> >> > (gdb) print p->infd > >> >> > > >> >> > and tell what that produces. > >> >> > >> >> The p->infd value is 8. > >> > > >> > OK, please repeat this several times to make sure it's always 8. > >> > > >> > If it is, then let's try to see which code leaves the .thread field > >> > uncleared. Like this (please run from the src directory where you > >> > have the 'emacs' executable you have built): > >> > > >> > $ gdb ./emacs > >> > ... > >> > (gdb) break process.c:8731 > >> > (gdb) run > >> > > >> > Emacs will start and stop in init_process_emacs, on line 8731 of > >> > process.c. Then: > >> > > >> > (gdb) watch fd_callback_info[8].thread > >> > (gdb) commands > >> > > bt 5 > >> > > continue > >> > > end > >> > (gdb) continue > >> > > >> > The above sets a watchpoint which will stop Emacs each time we assign > >> > some value to fd_callback_info[8].thread, and GDB will then show the > >> > first 5 frames of the call-stack, then continue. Now run your recipe, > >> > until it gets SIGABRT, and post everything GDB produced until that > >> > point. I hope that will tell us which code fails to clear the .thread > >> > member. > >> > > >> > Thanks. > >> > >> The fd is 8 when running Emacs in terminal. > >> The fd is always 16 when running Emacs in X11. > > > > Thanks, please try the patch below, instead of the incorrect one I > > asked you to try before: > > > > diff --git a/src/process.c b/src/process.c > > index fa003c2..736098f 100644 > > --- a/src/process.c > > +++ b/src/process.c > > @@ -4831,7 +4831,11 @@ deactivate_process (Lisp_Object proc) > > /* Beware SIGCHLD hereabouts. */ > > > > for (i = 0; i < PROCESS_OPEN_FDS; i++) > > - close_process_fd (&p->open_fd[i]); > > + { > > + fd_callback_info[p->open_fd[i]].thread = NULL; > > + fd_callback_info[p->open_fd[i]].waiting_thread = NULL; > > + close_process_fd (&p->open_fd[i]); > > + } > > > > inchannel = p->infd; > > eassert (inchannel < FD_SETSIZE); > > This resolves the problem. The assertion failure no longer occurs when testing with the patch. Thanks, now installed on the master branch. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Zhengyi Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 10:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175715420213240 (code B ref 79367); Sat, 06 Sep 2025 10:24:02 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 10:23:22 +0000 Received: from localhost ([127.0.0.1]:34584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuq4o-0003RU-A8 for submit@debbugs.gnu.org; Sat, 06 Sep 2025 06:23:22 -0400 Received: from relay8-d.mail.gandi.net ([2001:4b98:dc4:8::228]:37005) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuq4j-0003R7-48 for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 06:23:19 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id C1B1E433BF; Sat, 6 Sep 2025 10:23:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1757154188; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GanXarP2+IQhzZIqPJIpl//xpxne15oU35JtRN6+wLQ=; b=mV3Ak31o4qaJ+D52G1RV7OOtteuD/+mkfiUGBwOCvTbDi5Vi8P0I2M+yxM6pFYhumMI+B5 nP4sl+OWw3DQZVh9opweQOzDFsE10Q5sJ3Og9GssJ3CDYBSTsjBiIv/uw2/lZGTembCGFX YLKV9tK8gU78OnTkP/1htlJy5KhefgKpYNsgVX4Yv3suEgcnPK1BuEKklCfJwby9pvWekj GjdTH9d1FKj9zegKBSI3ulJUsJyJA+XbmrwMKXh55iyMdaPuqoOODaYzxKkVroLyU1v4tV JKyxAa/JjeMpbbsHUsjUJyRCIshsPsnwEeff6v10/E9ocBH6v6e1sOZSl2fW+w== From: Zhengyi Fu In-Reply-To: <86ms77gbk2.fsf@gnu.org> References: <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> <87tt1h2g1l.fsf@fuzy.me> <86frd1hvyr.fsf@gnu.org> <87plc52f8v.fsf@fuzy.me> <86ecslhskx.fsf@gnu.org> <87v7lww3be.fsf@fuzy.me> <86seh0ghvs.fsf@gnu.org> <87frd00ytj.fsf@fuzy.me> <86ms77gbk2.fsf@gnu.org> Date: Sat, 06 Sep 2025 18:23:03 +0800 Message-ID: <87wm6bc22g.fsf@fuzy.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduudehvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghffffkfgggtgesthdtredttdertdenucfhrhhomhepkghhvghnghihihcuhfhuuceoihesfhhuiiihrdhmvgeqnecuggftrfgrthhtvghrnheptedvueevffejudfgtdejuefgjeejgedtkeetfefftdeggfffteffieeuhfdtgeefnecukfhppeeghedrkedrudekiedruddtvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeghedrkedrudekiedruddtvddphhgvlhhopegtrghllhhiohhpvgdpmhgrihhlfhhrohhmpehisehfuhiihidrmhgvpdhnsggprhgtphhtthhopeegpdhrtghpthhtohepjeelfeeijeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopegumhhithhrhiesghhuthhovhdruggvvhdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhg X-GND-Sasl: id@fuzy.me X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: > Thanks, now installed on the master branch. Thank you very much! From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 10:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Zhengyi Fu Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175715503015826 (code B ref 79367); Sat, 06 Sep 2025 10:38:02 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 10:37:10 +0000 Received: from localhost ([127.0.0.1]:34604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuqI9-00047C-MP for submit@debbugs.gnu.org; Sat, 06 Sep 2025 06:37:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52990) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuqI5-00046c-Sy for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 06:37:07 -0400 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 1uuqHx-0006yj-46; Sat, 06 Sep 2025 06:36:57 -0400 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=Yg4WRnYwphLvJd8nFrXKlrFWbMW3G3iOz4CC4BA4tCQ=; b=P+jyWXXgxHrz uPb2NrdbsgLjRWk1EGKnLNfZKADgqT0Vu9hpEmq0YUFbrTChFKQXJKwQRtEqgn1XsHskLCuOtg3s9 W8ytVi6u75aZ5rdFxk0elsZ3HdN/JOT2V7KcM0UKjSGgbzY7IvVgEAwI5DkifUibTkIQC6MPVlUc+ 1H2Mepz+TmAHDcD18xRAQwiWLvENZTwE0NRP0oakVVYjvVjTfD0zuMR3k2FH1KU7syDlsY49PfAHX 54ahGCx7vePWtlZWfTYHmgj/RzIZj7iJNvi8lf/o+L9r9M6fBReUOWHddf+5xas/rXXH/LS+aCG3C zDToZ+tTEmA16FqozSQuow==; Date: Sat, 06 Sep 2025 13:36:54 +0300 Message-Id: <86ikhvg94p.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87wm6bc22g.fsf@fuzy.me> (message from Zhengyi Fu on Sat, 06 Sep 2025 18:23:03 +0800) References: <86o6rrk1fy.fsf@gnu.org> <86ldmvjxmg.fsf@gnu.org> <86ikhykem2.fsf@gnu.org> <86zfbahvka.fsf@gnu.org> <86wm6digvw.fsf@gnu.org> <86o6rpi3jy.fsf@gnu.org> <86ldmti1w0.fsf@gnu.org> <87tt1h2g1l.fsf@fuzy.me> <86frd1hvyr.fsf@gnu.org> <87plc52f8v.fsf@fuzy.me> <86ecslhskx.fsf@gnu.org> <87v7lww3be.fsf@fuzy.me> <86seh0ghvs.fsf@gnu.org> <87frd00ytj.fsf@fuzy.me> <86ms77gbk2.fsf@gnu.org> <87wm6bc22g.fsf@fuzy.me> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zhengyi Fu > Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > Date: Sat, 06 Sep 2025 18:23:03 +0800 > > Eli Zaretskii writes: > > > Thanks, now installed on the master branch. > > Thank you very much! Thanks for helping debug this. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Vincenzo Pupillo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 14:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: i@fuzy.me, 79367@debbugs.gnu.org Cc: dmitry@gutov.dev, sbaugh@janestreet.com, eliz@gnu.org X-Debbugs-Original-To: Zhengyi Fu , bug-gnu-emacs@gnu.org X-Debbugs-Original-Cc: dmitry@gutov.dev, sbaugh@janestreet.com, Eli Zaretskii , 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17571676067508 (code B ref 79367); Sat, 06 Sep 2025 14:07:02 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 14:06:46 +0000 Received: from localhost ([127.0.0.1]:36626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uutYx-0001wu-EB for submit@debbugs.gnu.org; Sat, 06 Sep 2025 10:06:46 -0400 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:49422) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uutYr-0001wP-0Z for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 10:06:40 -0400 Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-45b7c01a708so11088585e9.3 for <79367@debbugs.gnu.org>; Sat, 06 Sep 2025 07:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757167590; x=1757772390; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TvpK3U9qM4xMRXZmE7dlWYpk5oBSe3Otpjji2bKDTrE=; b=mvGBW9IiAhqOYZtih06RV3ffiVV32SZwEyFeUwv350DB33z74H+VNHDn26fumIUpGF /8CaE7HAp3/rgyRM/XXUUKE5LUUI7KSsv47ygr7ucfAFq4zXsr+bFJg8147ELMceQxsP vrvej2h0CImur+Lqd0CMdiAhVemrVgdqoULgc6v/YTka0Qjj2TDcsggvGLKBXmL2yQjE JvKgZtVvlu1QKCj8RVsV0UFqlR6pTN2TfJzvhqlYrjSfIanlF6uV3uOz4pqUlWEG2NWS Ymgcj0KioPwVfzfq7Gc7+bCmvYRFGAsSdTk3W9GjfZBfQNbof0TXiEbsxWbyryCHoS6W buTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757167590; x=1757772390; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TvpK3U9qM4xMRXZmE7dlWYpk5oBSe3Otpjji2bKDTrE=; b=k7rrf2yb481ZtgtmxcnLAQrJ/7YwbQ7aVRIbMhhhKtJhd5uBK9+6xvR+9BLmNKEL/+ QLfIi/L/mhaH7s5ZbpwCFsTA3qF2Ump46Fmx/FW4JcpTT5ufCTIDYWwJ7NeRvn1fH/UF vWtav2razG85Wr1CiqaLMJnRtECgQJKGSPvf+1rg1kdYZZM5wRq5RECaNWMFNQsJkShJ 4CJ5kaLzVtEzVeZjBr+YRgT9Ea6RO5snV9yiD6ImkqYG2vk/wqVxoEIyHSh9zZMuF4jv vYpg3YspMFOGtJITkazB4c+QaOn90NxqNQgw1DEfX3Jhum88zpVAw2H4PFih/1gDqIFP l6jw== X-Forwarded-Encrypted: i=1; AJvYcCV1kJqzbaWYWw4/qZYtakaGHgHYCvHB4AE7TynXAWEha+NWtOMrYcxC0L7iPr/J45cMJOEiOA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyqjeQImOQEsomRMjxikmxjNx2Er/8a4sLuLXcpr+8nkUgcsvKZ onwC0yET+tB0mIUlNVX4io8Xj9I6VPthfuAUF8DrJDJEwq4OAle5DfsW X-Gm-Gg: ASbGncsiJVHHFAf1r/gjTpAOG2Oe5V8j4mlcECXz/2cqMnTy0VTnhO+GYrRlhLdOa9u 5yl/+y+ayd+bRKxf2D918Dkl4WS5aAEbMF+DWNalEZwqZDNL410eCwtjC03aHs6yavq9X4L0dbs PtdHD9MyU8hzdRSD8vw+79GUW47+v5KRqJt84HwfESdRcj3MUuuj94XbowJbu/xZER8b4r1NpV2 uIyDUja6jXcXzTIYtxxGBq3csmAbizIUhXEYMjeSO4EXV548CPg2nEMghn7xSv9MkO9Uuq7Z1M3 gWpRYjXMhtlIP4S+NwEtLxk//Yr69BzHBKBeqMic6LqeNV+c3iol+eaH7GIAdvaxcIaB/u66Otr zIxzTP+rkLcvZu0XiizbGJJIli+xuLs521CSFWYwQPhtYfVqvIOrpKuHuzFA8mmj53ZssnbyPnA == X-Google-Smtp-Source: AGHT+IH+7TILrdv79rb+NdOSporSdhSW9Iasqe2wX1pRf3I2NVkwVgcsjD5qqQT9dd9FiyiY123h0A== X-Received: by 2002:a05:600c:3509:b0:459:443e:b177 with SMTP id 5b1f17b1804b1-45dddeefddbmr17406285e9.25.1757167589679; Sat, 06 Sep 2025 07:06:29 -0700 (PDT) Received: from fedora.localnet (2-230-139-124.ip202.fastwebnet.it. [2.230.139.124]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d9f3c36a78sm19342319f8f.48.2025.09.06.07.06.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Sep 2025 07:06:28 -0700 (PDT) From: Vincenzo Pupillo Date: Sat, 06 Sep 2025 16:06:27 +0200 Message-ID: <3658687.dWV9SEqChM@fedora> In-Reply-To: <86ikhvg94p.fsf@gnu.org> References: <87wm6bc22g.fsf@fuzy.me> <86ikhvg94p.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart5725748.rdbgypaU67" Content-Transfer-Encoding: 7Bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --nextPart5725748.rdbgypaU67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Ciao Eli, after the commit 6c150961fd07e19b6c871d8963d6b9826ec8140f (HEAD) = to=20 the master emacs --daemon (with my configuration) now uses 100% of the CPU= =20 even if nothing at all is being done in a client. Checking out 6b42b974ceabba8b0215498d4a6eb5048d91514d and recompiling fix t= he=20 issue. Could the issue be related to this commit on src/process.c? Thanks. Vincenzo In GNU Emacs 31.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.24.49, cairo version 1.18.2) of 2025-09-06 built on fedora Repository revision: 2ecced627bc6553003bc32e282629273d2f9c454 Repository branch: master System Description: Fedora Linux 42 (KDE Plasma Desktop Edition) Configured using: 'configure --disable-gc-mark-trace --with-native-compilation=3Daot --with-tree-sitter --with-cairo --without-pop --without-imagemagick --prefix=3D/opt/emacs_pgtk --with-file-notification=3Dinotify --enable-link-time-optimization --with-xinput2 --with-pgtk 'CFLAGS=3D -O2 -mtune=3Dnative -march=3Dnative -pipe '' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB Important settings: value of $LANG: it_IT.UTF-8 value of $XMODIFIERS: @im=3Dnone locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: marginalia-mode: t xclip-mode: t recentf-mode: t which-key-mode: t server-mode: t yas-minor-mode: t global-git-gutter-mode: t editorconfig-mode: t persp-mode: t global-projection-hook-mode: t corfu-popupinfo-mode: t corfu-history-mode: t global-corfu-mode: t corfu-mode: t vertico-mode: t override-global-mode: t windmove-mode: t electric-pair-mode: t which-function-mode: t save-place-mode: t winner-mode: t minibuffer-electric-default-mode: t global-hl-line-mode: t savehist-mode: t delete-selection-mode: t xterm-mouse-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t context-menu-mode: t global-font-lock-mode: t font-lock-mode: t minibuffer-regexp-mode: t column-number-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t temp-buffer-resize-mode: t Load-path shadows: /home/vincenzo/.emacs.d/elpa/transient-20250903.1516/transient hides /opt/ emacs_pgtk/share/emacs/31.0.50/lisp/transient /home/vincenzo/.emacs.d/elpa/standard-themes-2.2.0/theme-loaddefs hides /op= t/ emacs_pgtk/share/emacs/31.0.50/lisp/theme-loaddefs =46eatures: (shadow sort mail-extr emacsbug lisp-mnt message yank-media puny citre-lang-fileref citre-tags citre-ctags citre-readtags citre-readtags-tables citre-backend-interface citre-common-tag citre-common-util dired-x dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils help-fns radix-tree mule-util vertico-sort tramp-cmds ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util smerge-mode diff-mode track-changes diff mvn vterm tramp trampver tramp-integration tramp-message tramp-compat parse-time iso8601 time-date tramp-loaddefs face-remap color term disp-table shell pcomplete ehelp find-func vterm-module term/xterm xterm multiple-cursors mc-separate-operations rectangular-region-mode mc-mark-pop mc-edit-lines mc-hide-unmatched-lines-mode mc-mark-more sgml-mode facemenu dom mc-cycle-cursors multiple-cursors-core rect marginalia rg files-x vc vc-dispatcher rg-info-hack rg-menu rg-ibuffer rg-result wgrep-rg wgrep rg-history rg-header ibuf-ext ibuffer ibuffer-loaddefs grep xclip recentf tree-widget which-key add-log compile comint ansi-osc ansi-color server yasnippet-snippets yasnippet git-gutter editorconfig editorconfig-core editorconfig-core-handle editorconfig-fnmatch comp comp-cstr warnings comp-run comp-common perspective advice thingatpt rx ido projection-hook projection-core projection-core-match projection-core-type projection-core-log projection-core-cache projection-core-misc projection-core-completion s init custom-vp-gen custom-elixir custom-lua custom-rust custom-dart custom-java custom-go custom-perl custom-php custom-c custom-sql custom-clojure custom-lisp custom-web custom-org custom-markup citre-config eldoc-box corfu-popupinfo corfu-history corfu project consult bookmark text-property-search orderless vertico use-package-ensure use-package-bind-key bind-key treesit standard-dark-theme standard-themes cl-extra help-mode windmove use-package-core elec-pair which-func imenu saveplace winner ring minibuf-eldef easy-mmode hl-line savehist delsel xt-mouse custom-function transient format-spec edmacro kmacro compat custom-variable fonts cus-edit pp cus-start cus-load wid-edit cape-autoloads cargo-autoloads citre-autoloads clj-refactor-autoloads cider-autoloads clojure-mode-autoloads composer-autoloads consult-dir-autoloads consult-lsp-autoloads consult-autoloads corfu-autoloads cuda-mode-autoloads debbugs-autoloads denote-explore-autoloads denote-markdown-autoloads denote-org-autoloads denote-autoloads devdocs-autoloads dired-rsync-autoloads disaster-autoloads docker-autoloads aio-autoloads eldoc-box-autoloads expand-region-autoloads extempore-mode-autoloads flutter-autoloads git-gutter-autoloads go-translate-autoloads gptel-autoloads highlight-indentation-autoloads hover-autoloads iedit-autoloads inflections-autoloads kotlin-ts-mode-autoloads lice-autoloads lsp-dart-autoloads dart-mode-autoloads lsp-java-autoloads dap-mode-autoloads lsp-docker-autoloads bui-autoloads lsp-pyright-autoloads lsp-python-refly-autoloads lsp-treemacs-autoloads lsp-ui-autoloads lsp-mode-autoloads magit-autoloads pcase magit-section-autoloads llama-autoloads cond-let-autoloads marginalia-autoloads mathjax-autoloads meson-mode-autoloads multiple-cursors-autoloads mvn-autoloads nexus-autoloads orderless-autoloads ox-pandoc-autoloads paredit-autoloads parseedn-autoloads parseclj-autoloads pdd-autoloads perspective-autoloads php-runtime-autoloads plantuml-mode-autoloads deflate-autoloads popup-autoloads projection-multi-autoloads compile-multi-autoloads projection-autoloads pyenv-mode-autoloads pythonic-autoloads pyvenv-autoloads qml-mode-autoloads queue-autoloads request-autoloads restclient-autoloads rg-autoloads rustic-autoloads markdown-mode-autoloads f-autoloads rust-mode-autoloads rvm-autoloads sesman-autoloads sly-autoloads spinner-autoloads standard-themes-autoloads tablist-autoloads transient-autoloads treemacs-autoloads cfrs-autoloads posframe-autoloads ht-autoloads hydra-autoloads lv-autoloads pfuture-autoloads ace-window-autoloads avy-autoloads s-autoloads dash-autoloads vertico-autoloads vterm-autoloads web-mode-autoloads wgrep-autoloads info with-editor-autoloads xclip-autoloads xcscope-autoloads xr-autoloads xterm-color-autoloads yaml-autoloads yasnippet-snippets-autoloads yasnippet-autoloads zig-mode-autoloads reformatter-autoloads package browse-url xdg url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib early-init rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo gtk pgtk lcms2 multi-tty move-toolbar make-network-process tty-child-frames native-compile emacs) Memory information: ((conses 16 361739 33614) (symbols 48 27047 0) (strings 32 92022 7674) (string-bytes 1 3573207) (vectors 16 43793) (vector-slots 8 520774 9737) (floats 8 280 6) (intervals 56 1425 0) (buffers 1064 12)) In data sabato 6 settembre 2025 12:36:54 Ora legale dell=E2=80=99Europa cen= trale, Eli=20 Zaretskii ha scritto: > > From: Zhengyi Fu > > Cc: sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org > > Date: Sat, 06 Sep 2025 18:23:03 +0800 > >=20 > > Eli Zaretskii writes: > > > Thanks, now installed on the master branch. > >=20 > > Thank you very much! >=20 > Thanks for helping debug this. --nextPart5725748.rdbgypaU67 Content-Disposition: attachment; filename="profile_cpu.txt" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; name="profile_cpu.txt" [profiler-profile "28.1" cpu #s(hash-table test equal data ([redisplay_inte= rnal\ \(C\ function\) nil nil nil nil nil nil nil nil nil nil nil nil nil n= il nil] 11 [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil= ] 17486 [execute-extended-command--shorter "#" appl= y timer-event-handler nil nil nil nil nil nil nil nil nil nil nil nil] 1 [c= ommandp "#" execute-extended-command--shorter "#" apply timer-event-handler nil nil nil nil nil nil ni= l nil nil nil] 2 ["#" execute-extended-command--sho= rter "#" apply timer-event-handler nil nil nil nil = nil nil nil nil nil nil nil] 2 [commandp "#" "#" all-completions complete-with-action "#" completion-= pcm--all-completions completion-basic-all-completions "#" funcall let eval "#" "#" mapc seq-do] 6 ["#" all-completions complete-w= ith-action "#" completion-pcm--all-completions completion-basic-all-comple= tions "#" funcall let eval "#" "#" mapc seq-do seq-some completion--nth-comple= tion] 6 [all-completions complete-with-action "#" completion-pcm--all-comp= letions completion-basic-all-completions "#" funcal= l let eval "#" "#" mapc seq= =2Ddo seq-some completion--nth-completion "#"] 33 ["#" "#" all-completions complete-with-action "#" completion-pcm--all-complet= ions completion-basic-all-completions "#" funcall l= et eval "#" "#" mapc seq-do= seq-some] 1 [vertico-sort-history-length-alpha vertico--recompute vertico-= =2Dupdate "#" "#" handler-bind-1 vertico--protect = vertico--exhibit "#" apply ve= rtico--advice apply completing-read-default read-extended-command-1 read-ex= tended-command byte-code] 1 ["#" vertico-sort-history-length-alpha vertico-= =2Drecompute vertico--update "#" "#" handler-bind-= 1 vertico--protect vertico--exhibit "#" apply vertico--advice apply completing-read-default read-exten= ded-command-1 read-extended-command] 1 [marginalia-annotate-command margina= lia--cached marginalia--affixate apply "#" vertico-= =2Daffixate vertico--arrange-candidates "#" "#" ha= ndler-bind-1 vertico--protect vertico--exhibit "#" apply vertico--advice apply] 1 [text-quoting-style su= bstitute-command-keys documentation marginalia--function-doc marginalia-ann= otate-command marginalia--cached marginalia--affixate apply "#" vertico--affixate vertico--arrange-candidates "#" "#" handler-bind-1 vertico--protect vertico--exhibit] 1 [file-= remote-p redisplay_internal\ \(C\ function\) "#" apply vertico--advice apply completing-read-default rea= d-extended-command-1 read-extended-command byte-code command-execute nil ni= l nil nil nil] 1 [redisplay_internal\ \(C\ function\) "#" apply vertico--advice apply completing-read-de= fault read-extended-command-1 read-extended-command byte-code command-execu= te nil nil nil nil nil nil] 18 ["#" apply vertico--advice apply completing-read-default read-extended-co= mmand-1 read-extended-command byte-code command-execute nil nil nil nil nil= nil nil] 3495 [redisplay_internal\ \(C\ function\) redisplay vertico--upda= te "#" "#" handler-bind-1 vertico--protect vertico= =2D-exhibit "#" apply vertico= =2D-advice apply completing-read-default read-extended-command-1 read-exten= ded-command byte-code] 3 [kill-buffer "#" substitut= e-command-keys documentation marginalia--function-doc marginalia-annotate-c= ommand marginalia--cached marginalia--affixate apply "#" vertico--affixate vertico--arrange-candidates "#" "#" handler-bind-1 vertico--protect] 1 [window-text-pixel-size vertic= o--resize-window vertico--display-candidates "#" "#" handler-bind-1 vertico--protect vertico--exhibit "#" apply vertico--advice apply completing-read-defa= ult read-extended-command-1 read-extended-command byte-code] 1 [jit-lock-co= ntext-fontify jit-lock-context--update apply timer-event-handler "#" apply vertico--advice apply complet= ing-read-default read-extended-command-1 read-extended-command byte-code co= mmand-execute nil nil nil] 1 [timer--activate timer-activate-when-idle time= r-event-handler "#" apply ver= tico--advice apply completing-read-default read-extended-command-1 read-ext= ended-command byte-code command-execute nil nil nil nil] 1 ["#" ad-Advice-execute-extended-command appl= y execute-extended-command funcall-interactively command-execute nil nil ni= l nil nil nil nil nil nil nil] 1 [Automatic\ GC nil] 535)) (26812 14938 769= 848 335000) nil] --nextPart5725748.rdbgypaU67 Content-Disposition: attachment; filename="profile_mem.txt" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; name="profile_mem.txt" [profiler-profile "28.1" memory #s(hash-table test equal data ([profiler-st= art funcall-interactively command-execute "#" ad-Advice-execute-extended-command apply execute-extended= =2Dcommand funcall-interactively command-execute nil nil nil nil nil nil ni= l] 663 [timer--time-setter timer-set-time run-at-time "#" ad-Advice-execute-extended-command apply exec= ute-extended-command funcall-interactively command-execute nil nil nil nil = nil nil nil] 24 [timer--time-less-p timer--activate timer-activate run-at-t= ime "#" ad-Advice-execute-ex= tended-command apply execute-extended-command funcall-interactively command= =2Dexecute nil nil nil nil nil nil] 24 [timer--time-setter timer-set-idle-t= ime run-with-idle-timer eldoc-schedule-timer nil nil nil nil nil nil nil ni= l nil nil nil nil] 24 [corfu--match-symbol-p "#" "#" handler-bind-1 corfu--protect corfu--auto-post-command nil nil nil nil n= il nil nil nil nil nil] 3200 [redisplay_internal\ \(C\ function\) nil nil n= il nil nil nil nil nil nil nil nil nil nil nil nil] 71744 [file-remote-p re= display_internal\ \(C\ function\) nil nil nil nil nil nil nil nil nil nil n= il nil nil nil] 11944 [generate-new-buffer project--value-in-dir project-tr= y-vc--search project-try-vc run-hook-with-args-until-success project--find-= in-directory project-current project-mode-line-format eval redisplay_intern= al\ \(C\ function\) nil nil nil nil nil nil] 42 [abbreviate-file-name locat= e-dominating-file dir-locals-find-file hack-dir-local--get-variables "#" hack-dir-local-variables project--value-in-dir projec= t-try-vc--search project-try-vc run-hook-with-args-until-success project--f= ind-in-directory project-current project-mode-line-format eval redisplay_in= ternal\ \(C\ function\) nil] 1152 [locate-dominating-file dir-locals-find-f= ile hack-dir-local--get-variables "#" hack-dir-loca= l-variables project--value-in-dir project-try-vc--search project-try-vc run= =2Dhook-with-args-until-success project--find-in-directory project-current = project-mode-line-format eval redisplay_internal\ \(C\ function\) nil nil] = 1152 [dir-locals--all-files dir-locals--base-file locate-dominating-file di= r-locals-find-file hack-dir-local--get-variables "#= " hack-dir-local-variables project--value-in-dir project-try-vc--search pro= ject-try-vc run-hook-with-args-until-success project--find-in-directory pro= ject-current project-mode-line-format eval redisplay_internal\ \(C\ functio= n\)] 10232 [wildcard-to-regexp "#" project-try-vc--search project-try-vc r= un-hook-with-args-until-success project--find-in-directory project-current = project-mode-line-format eval redisplay_internal\ \(C\ function\) nil nil n= il nil nil nil] 9336 ["#" project-try-vc--search project-try-vc run-hook-w= ith-args-until-success project--find-in-directory project-current project-m= ode-line-format eval redisplay_internal\ \(C\ function\) nil nil nil nil ni= l nil nil] 1862 [directory-files "#" locate-dominat= ing-file project-try-vc--search project-try-vc run-hook-with-args-until-suc= cess project--find-in-directory project-current project-mode-line-format ev= al redisplay_internal\ \(C\ function\) nil nil nil nil nil] 9528 [mode-line= =2D-minor-modes eval redisplay_internal\ \(C\ function\) nil nil nil nil ni= l nil nil nil nil nil nil nil nil] 32 [nil nil nil nil nil nil nil nil nil = nil nil nil nil nil nil nil] 337364096 [timer-event-handler nil nil nil nil= nil nil nil nil nil nil nil nil nil nil nil] 11083 [re-search-backward beg= inning-of-defun-raw beginning-of-defun lisp-current-defun-name add-log-curr= ent-defun which-function which-func-update-1 which-func-update apply timer-= event-handler nil nil nil nil nil nil] 1024 [lisp-current-defun-name add-lo= g-current-defun which-function which-func-update-1 which-func-update apply = timer-event-handler nil nil nil nil nil nil nil nil nil] 1024 [execute-exte= nded-command--shorter-1 execute-extended-command--shorter-1 execute-extende= d-command--shorter "#" apply timer-event-handler ni= l nil nil nil nil nil nil nil nil nil] 1152 [format-message imenu-unavailab= le-error imenu-default-create-index-function which-func-ff-hook run-hooks r= un-mode-hooks minibuffer-mode "#" apply vertico--advice apply completing-read-default read-extended-comm= and-1 read-extended-command byte-code command-execute] 1321 [format-message= imenu-unavailable-error imenu-default-create-index-function which-func-ff-= hook run-hooks run-mode-hooks minibuffer-inactive-mode "#" apply vertico--advice apply completing-read-d= efault read-extended-command-1 read-extended-command byte-code command-exec= ute] 2642 ["#" apply vertico-= =2Dadvice apply completing-read-default read-extended-command-1 read-extend= ed-command byte-code command-execute nil nil nil nil nil nil nil] 65421700 = [timer--time-setter timer-set-time run-at-time undo-auto--boundary-ensure-t= imer undo-auto--undoable-change "#" apply vertico--advice apply completing-read-default read-extended-co= mmand-1 read-extended-command byte-code command-execute nil nil] 24 [timer-= =2Dtime-less-p timer--activate timer-activate run-at-time undo-auto--bounda= ry-ensure-timer undo-auto--undoable-change "#" apply vertico--advice apply completing-read-default read-= extended-command-1 read-extended-command byte-code command-execute nil] 24 = [make-overlay vertico--setup minibuffer-setup "#" apply vertico--advice apply completing-read-default re= ad-extended-command-1 read-extended-command byte-code command-execute nil n= il nil nil] 184 [marginalia--cache-reset marginalia--minibuffer-setup "#" apply vertico--advice apply co= mpleting-read-default read-extended-command-1 read-extended-command byte-co= de command-execute nil nil nil nil nil] 2912 [minibuf-eldef-setup-minibuffe= r "#" apply vertico--advice a= pply completing-read-default read-extended-command-1 read-extended-command = byte-code command-execute nil nil nil nil nil nil] 4608 [minibuffer--regexp= =2Dsetup "#" apply vertico--a= dvice apply completing-read-default read-extended-command-1 read-extended-c= ommand byte-code command-execute nil nil nil nil nil nil] 1152 [string-matc= h pgtk-device-class device-class minibuffer-setup-on-screen-keyboard "#" apply vertico--advice apply com= pleting-read-default read-extended-command-1 read-extended-command byte-cod= e command-execute nil nil nil] 1024 [completion-pcm--pattern->regex complet= ion-pcm--all-completions completion-basic-all-completions "#" funcall let eval "#" "#" mapc seq-do seq-some completion--nth-completion "#" apply completion-all-completions] 1152 [= all-completions complete-with-action "#" completion-pcm--all-completions c= ompletion-basic-all-completions "#" funcall let eva= l "#" "#" mapc seq-do seq-s= ome completion--nth-completion "#"] 99528 [version-to-list "#" all-completion= s complete-with-action "#" completion-pcm--all-completions completion-basi= c-all-completions "#" funcall let eval "#" "#" mapc seq-do seq-some] 3200 [f= ormat-message error version-to-list "#" all-complet= ions complete-with-action "#" completion-pcm--all-completions completion-b= asic-all-completions "#" funcall let eval "#" "#" mapc] 51060 [tramp-tramp-fil= e-p "#" mapcar "#" apply seq-map tramp-compat-seq-= keep tramp-list-remote-buffers tramp-active-command-completion-p command-co= mpletion-default-include-p "#" "#" all-completions complete-with-action "#" completion-pcm--all-compl= etions] 3736 [completion-pcm--all-completions completion-basic-all-completi= ons "#" funcall let eval "#= " "#" mapc seq-do seq-some completion--nth-completi= on "#" apply completion-al= l-completions vertico--filter-completions] 98376 [vertico-sort--history ver= tico-sort-history-length-alpha vertico--recompute vertico--update "#" "#= " handler-bind-1 vertico--protect vertico--exhibit = "#" apply vertico--advice app= ly completing-read-default read-extended-command-1 read-extended-command] 2= 912 [vertico-sort-history-length-alpha vertico--recompute vertico--update "= #" "#" handler-bind-1 vertico--protect vertico--ex= hibit "#" apply vertico--advi= ce apply completing-read-default read-extended-command-1 read-extended-comm= and byte-code] 69728 [vertico--format-count vertico--display-count "#" "#<= byte-code-function 4CF>" handler-bind-1 vertico--protect vertico--exhibit "= #" apply vertico--advice appl= y completing-read-default read-extended-command-1 read-extended-command byt= e-code command-execute] 13596 [marginalia-annotate-binding marginalia-annot= ate-command marginalia--cached marginalia--affixate apply "#" vertico--affixate vertico--arrange-candidates "#" "#" handler-bind-1 vertico--protect vertico--exhibit "#" apply vertico--advice] 76003 [intern= al-subr-documentation "#" "#" apply function-documentation documentation marginalia--function-doc marg= inalia-annotate-command marginalia--cached marginalia--affixate apply "#" vertico--affixate vertico--arrange-candidates "#" "= #"] 13992 [generate-new-buffer substitute-command-k= eys documentation marginalia--function-doc marginalia-annotate-command marg= inalia--cached marginalia--affixate apply "#" verti= co--affixate vertico--arrange-candidates "#" "#" h= andler-bind-1 vertico--protect vertico--exhibit] 441 [substitute-command-ke= ys documentation marginalia--function-doc marginalia-annotate-command margi= nalia--cached marginalia--affixate apply "#" vertic= o--affixate vertico--arrange-candidates "#" "#" ha= ndler-bind-1 vertico--protect vertico--exhibit "#"] 81833 [string-match marginalia--function-doc margina= lia-annotate-command marginalia--cached marginalia--affixate apply "#" vertico--affixate vertico--arrange-candidates "#" "#= " handler-bind-1 vertico--protect vertico--exhibit = "#" apply] 1024 [marginalia--= truncate marginalia--documentation marginalia-annotate-command marginalia--= cached marginalia--affixate apply "#" vertico--affi= xate vertico--arrange-candidates "#" "#" handler-b= ind-1 vertico--protect vertico--exhibit "#" apply] 8 [marginalia--affixate apply "#" vertico--affixate vertico--arrange-candidates "#" "#" handler-bind-1 vertico--protect vertico--exhibit "#" apply vertico--advice apply completing-r= ead-default read-extended-command-1] 1024 [buffer-string substitute-command= =2Dkeys documentation marginalia--function-doc marginalia-annotate-command = marginalia--cached marginalia--affixate apply "#" v= ertico--affixate vertico--arrange-candidates "#" "#" handler-bind-1 vertico--protect vertico--exhibit] 7624 [marginalia--docu= mentation marginalia-annotate-command marginalia--cached marginalia--affixa= te apply "#" vertico--affixate vertico--arrange-can= didates "#" "#" handler-bind-1 vertico--protect ve= rtico--exhibit "#" apply vert= ico--advice] 1016 [vertico--format-candidate vertico--arrange-candidates "#= " "#" handler-bind-1 vertico--protect vertico--exh= ibit "#" apply vertico--advic= e apply completing-read-default read-extended-command-1 read-extended-comma= nd byte-code command-execute] 26528 [vertico--display-string vertico--forma= t-candidate vertico--arrange-candidates "#" "#" ha= ndler-bind-1 vertico--protect vertico--exhibit "#" apply vertico--advice apply completing-read-default r= ead-extended-command-1 read-extended-command byte-code] 10160 [concat verti= co--display-string vertico--format-candidate vertico--arrange-candidates "#= " "#" handler-bind-1 vertico--protect vertico--exh= ibit "#" apply vertico--advic= e apply completing-read-default read-extended-command-1 read-extended-comma= nd] 82912 [concat apply vertico--display-candidates "#" "#" handler-bind-1 vertico--protect vertico--exhibit "#" apply vertico--advice apply completing-re= ad-default read-extended-command-1 read-extended-command byte-code] 56160 [= window--resize-mini-window window-resize vertico--resize-window vertico--di= splay-candidates "#" "#" handler-bind-1 vertico--p= rotect vertico--exhibit "#" a= pply vertico--advice apply completing-read-default read-extended-command-1 = read-extended-command] 401 [timer--time-setter timer-set-idle-time run-with= =2Didle-timer eldoc-schedule-timer "#" apply vertico--advice apply completing-read-default read-extended= =2Dcommand-1 read-extended-command byte-code command-execute nil nil nil] 1= 6 [redisplay_internal\ \(C\ function\) "#" apply vertico--advice apply completing-read-default read-exte= nded-command-1 read-extended-command byte-code command-execute nil nil nil = nil nil nil] 126368 [marginalia--cache-reset redisplay_internal\ \(C\ funct= ion\) "#" apply vertico--advi= ce apply completing-read-default read-extended-command-1 read-extended-comm= and byte-code command-execute nil nil nil nil nil] 2912 [file-remote-p redi= splay_internal\ \(C\ function\) "#" apply vertico--advice apply completing-read-default read-extended-co= mmand-1 read-extended-command byte-code command-execute nil nil nil nil nil= ] 11336 [generate-new-buffer project--value-in-dir project-try-vc--search p= roject-try-vc run-hook-with-args-until-success project--find-in-directory p= roject-current project-mode-line-format eval redisplay_internal\ \(C\ funct= ion\) "#" apply vertico--advi= ce apply completing-read-default read-extended-command-1] 42 [abbreviate-fi= le-name locate-dominating-file dir-locals-find-file hack-dir-local--get-var= iables "#" hack-dir-local-variables project--value-= in-dir project-try-vc--search project-try-vc run-hook-with-args-until-succe= ss project--find-in-directory project-current project-mode-line-format eval= redisplay_internal\ \(C\ function\) "#"] 1024 [locate-dominating-file dir-locals-find-file hack-dir-loc= al--get-variables "#" hack-dir-local-variables proj= ect--value-in-dir project-try-vc--search project-try-vc run-hook-with-args-= until-success project--find-in-directory project-current project-mode-line-= format eval redisplay_internal\ \(C\ function\) "#" apply] 1024 [wildcard-to-regexp "#" project-try-vc-= =2Dsearch project-try-vc run-hook-with-args-until-success project--find-in-= directory project-current project-mode-line-format eval redisplay_internal\= \(C\ function\) "#" apply ve= rtico--advice apply completing-read-default read-extended-command-1] 1024 [= "#" project-try-vc--search project-try-vc run-hook-with-args-until-success= project--find-in-directory project-current project-mode-line-format eval r= edisplay_internal\ \(C\ function\) "#" apply vertico--advice apply completing-read-default read-extended= =2Dcommand-1 read-extended-command] 10046 [directory-files "#" locate-dominating-file project-try-vc--search project-try-vc ru= n-hook-with-args-until-success project--find-in-directory project-current p= roject-mode-line-format eval redisplay_internal\ \(C\ function\) "#" apply vertico--advice apply complet= ing-read-default] 1344 [mode-line--minor-modes eval redisplay_internal\ \(C= \ function\) "#" apply vertic= o--advice apply completing-read-default read-extended-command-1 read-extend= ed-command byte-code command-execute nil nil nil nil] 32 [timer-event-handl= er "#" apply vertico--advice = apply completing-read-default read-extended-command-1 read-extended-command= byte-code command-execute nil nil nil nil nil nil] 2568 [clear-minibuffer-= message "#" apply vertico--ad= vice apply completing-read-default read-extended-command-1 read-extended-co= mmand byte-code command-execute nil nil nil nil nil nil] 68933 [funcall-int= eractively command-execute "#= " apply vertico--advice apply completing-read-default read-extended-command= =2D1 read-extended-command byte-code command-execute nil nil nil nil nil] 9= 6 [self-insert-command funcall-interactively command-execute "#" apply vertico--advice apply completin= g-read-default read-extended-command-1 read-extended-command byte-code comm= and-execute nil nil nil nil] 312 [completion--hilit-from-re "#" vertico--hilit vertico--arrange-candidates "#" "#" handler-bind-1 vertico--protect vertico--exhibit "#" apply vertico--advice apply completin= g-read-default read-extended-command-1 read-extended-command] 5360 [redispl= ay_internal\ \(C\ function\) redisplay vertico--update "#" "#" handler-bind-1 vertico--protect vertico--exhibit "#" apply vertico--advice apply completing= =2Dread-default read-extended-command-1 read-extended-command byte-code] 12= 432 [command-execute "#" appl= y vertico--advice apply completing-read-default read-extended-command-1 rea= d-extended-command byte-code command-execute nil nil nil nil nil nil] 3 [de= lete-minibuffer-contents vertico-insert vertico-exit funcall-interactively = command-execute "#" apply ver= tico--advice apply completing-read-default read-extended-command-1 read-ext= ended-command byte-code command-execute nil nil] 56 [vertico-insert vertico= =2Dexit funcall-interactively command-execute "#" apply vertico--advice apply completing-read-default re= ad-extended-command-1 read-extended-command byte-code command-execute nil n= il nil] 104 ["#" ad-Advice-e= xecute-extended-command apply execute-extended-command funcall-interactivel= y command-execute nil nil nil nil nil nil nil nil nil nil] 75912 [funcall-i= nteractively command-execute "#" ad-Advice-execute-extended-command apply execute-extended-command func= all-interactively command-execute nil nil nil nil nil nil nil nil] 16 [prof= iler-stop funcall-interactively command-execute "#" ad-Advice-execute-extended-command apply execute-ex= tended-command funcall-interactively command-execute nil nil nil nil nil ni= l nil] 1561084 [Automatic\ GC nil] 50525)) (26812 14938 782378 383000) nil] --nextPart5725748.rdbgypaU67-- From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 14:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vincenzo Pupillo Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev X-Debbugs-Original-Cc: i@fuzy.me, sbaugh@janestreet.com, bug-gnu-emacs@gnu.org, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by submit@debbugs.gnu.org id=B.175716973114765 (code B ref -1); Sat, 06 Sep 2025 14:43:02 +0000 Received: (at submit) by debbugs.gnu.org; 6 Sep 2025 14:42:11 +0000 Received: from localhost ([127.0.0.1]:36783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuu7F-0003q5-Ot for submit@debbugs.gnu.org; Sat, 06 Sep 2025 10:42:10 -0400 Received: from lists.gnu.org ([2001:470:142::17]:59390) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuu76-0003pG-2I for submit@debbugs.gnu.org; Sat, 06 Sep 2025 10:42:01 -0400 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 1uuu6y-0004QO-Nn for bug-gnu-emacs@gnu.org; Sat, 06 Sep 2025 10:41:53 -0400 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 1uuu6o-0006CC-8z; Sat, 06 Sep 2025 10:41:46 -0400 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=UzikF1VaD1q02P+S81/R+AVYyN/eyL1xhynMMTWt1I8=; b=aqv3OY8epeJIJYbDP6QN 9ymARXJkt6v2NQsnFuIVdb3ci0x60o6jJd84PRvr04H9rAq7OcIefkg+MFDau8XZR7PDjVx4stTBb pXNsCxhxHl0E00pEjMRTdpcs2BY6H4o/z8b1ALeNzQnOX9/28EB/nmXZvwBccRQpjfVyI/hxQF7Tj 2d9vRjdzPtAeMdzlEln/BJA2RMsENxQfPux1OKkoou9+XxxztN+K9sztvduyyTwqx9bD7bLFOQBj7 hSEXq4AWcwr79fp7yV0fvm1KT0GTjrvWsecu0WPNCYFQUGVcLdwFcGCgeETzbAZZzRBRx7Y2Xa6Qk X4hTpNO5ZbvllQ==; Date: Sat, 06 Sep 2025 17:41:33 +0300 Message-Id: <86a537fxsy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <3658687.dWV9SEqChM@fedora> (message from Vincenzo Pupillo on Sat, 06 Sep 2025 16:06:27 +0200) References: <87wm6bc22g.fsf@fuzy.me> <86ikhvg94p.fsf@gnu.org> <3658687.dWV9SEqChM@fedora> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Vincenzo Pupillo > Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev, > Eli Zaretskii > Date: Sat, 06 Sep 2025 16:06:27 +0200 > > Ciao Eli, after the commit 6c150961fd07e19b6c871d8963d6b9826ec8140f (HEAD) to > the master emacs --daemon (with my configuration) now uses 100% of the CPU > even if nothing at all is being done in a client. > Checking out 6b42b974ceabba8b0215498d4a6eb5048d91514d and recompiling fix the > issue. Could the issue be related to this commit on src/process.c? I cannot reproduce this. Please show a recipe starting from how you start the daemon and then how you start the client. I tried the naïve thing, but 'top' didn't show any 100% CPU consumption by either the daemon or the client. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 14:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: v.pupillo@gmail.com Cc: i@fuzy.me, sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175717048917404 (code B ref 79367); Sat, 06 Sep 2025 14:55:02 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 14:54:49 +0000 Received: from localhost ([127.0.0.1]:36864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuuJV-0004We-3u for submit@debbugs.gnu.org; Sat, 06 Sep 2025 10:54:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40658) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuuJR-0004WA-3I for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 10:54:46 -0400 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 1uuuJF-000099-42; Sat, 06 Sep 2025 10:54:33 -0400 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=XqnRhzD27tOvd6X9R7P4Skrrm33Bziow/zkY2pJHo1M=; b=fGJQpfBZzhaYTc+pyW7U +mp/jlgH2yW6xAQviy0WFz3fHoAynNVnYOl1CZRg/IuCd6xTAbbR/3HQjqvobSsdpiC5QJuZAh/DQ NDqPq4lIwIfjzgJ4J6jCNTBpTN2udwZMM6Aj9pcuLxATQnoNQIYdYEH/ikIu/RX6615Eqe86H82I+ q4HMYtK1YNQcz/58Dw8kxJ41R9YYOPysVa1G2STtaNSj73e+eb9kYSnCRgUwy+8Z69we+3bclG5sY iiXGKqxIZhFU2Gjf69EktZMQ0bjYgn+3UrTq4q0TscHLHza15fSKEXwqeXkuL3G/cUFdg7EAgGNvE Nw1MfJBlH6P0Qg==; Date: Sat, 06 Sep 2025 17:54:30 +0300 Message-Id: <867bybfx7d.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86a537fxsy.fsf@gnu.org> (message from Eli Zaretskii on Sat, 06 Sep 2025 17:41:33 +0300) References: <87wm6bc22g.fsf@fuzy.me> <86ikhvg94p.fsf@gnu.org> <3658687.dWV9SEqChM@fedora> <86a537fxsy.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev > Date: Sat, 06 Sep 2025 17:41:33 +0300 > From: Eli Zaretskii > > > From: Vincenzo Pupillo > > Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev, > > Eli Zaretskii > > Date: Sat, 06 Sep 2025 16:06:27 +0200 > > > > Ciao Eli, after the commit 6c150961fd07e19b6c871d8963d6b9826ec8140f (HEAD) to > > the master emacs --daemon (with my configuration) now uses 100% of the CPU > > even if nothing at all is being done in a client. > > Checking out 6b42b974ceabba8b0215498d4a6eb5048d91514d and recompiling fix the > > issue. Could the issue be related to this commit on src/process.c? > > I cannot reproduce this. Please show a recipe starting from how you > start the daemon and then how you start the client. I tried the naïve > thing, but 'top' didn't show any 100% CPU consumption by either the > daemon or the client. However, I've just installed something to make that change safer. So before you post the recipe, please check if the latest master still exhibits the problematic behavior. From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Vincenzo Pupillo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 16:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: i@fuzy.me, sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.17571764074315 (code B ref 79367); Sat, 06 Sep 2025 16:34:01 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 16:33:27 +0000 Received: from localhost ([127.0.0.1]:37229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuvqw-00017U-Lf for submit@debbugs.gnu.org; Sat, 06 Sep 2025 12:33:27 -0400 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:51390) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uuvqm-00016v-CG for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 12:33:17 -0400 Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-45dd505a1dfso15772025e9.2 for <79367@debbugs.gnu.org>; Sat, 06 Sep 2025 09:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757176389; x=1757781189; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oTm+CTi9cRJQVHJ1pzvMgtriIJxt4mZq9MKurUVO8sA=; b=Bd22DgBQ3E5i2T4E/GL2aPa21IWfh+k7lckPbfDrjkBX9t51lEnopTuwtcImzp6L5D NrfxKXs4rTVdvXAGDDdw2I6WfiskanZCSFCGYzeA9reTyxfauL2SsROpsoaZAL38BsYb ZPpBk/OF3nJXDUm33z8REjtGPNXs4pXPzjYegO3SDMxYFNjdrFeDrr/xo3gqvsQp94LQ 4t+X3keoLnTQhfNsk/Is1eMBBFfEjXO1Ravuv/NCr7YBndZ36YgMGv7VbK47gm188+3q Me1iW3xXhR+HzkaHdWVZ0Feb6Gyql+DMj/dw286XzkpmuADZz3wU49Mt0QxFMlrhvGyJ Hs6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757176389; x=1757781189; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oTm+CTi9cRJQVHJ1pzvMgtriIJxt4mZq9MKurUVO8sA=; b=Wa7DnDbY5tjLkt5ZhlL6B+tkdrpNvQDup/c676owG6KwphQuE0LyD2h7pULi9JyTNi CGQho5JclyqLYbSNyhGPGYGlV+o8Nhz0IQE4UD38kb1r9ybYafs+ykA7/ocs4iTLYOL5 qM4aBY6Gb9a4h3/+Q2uMm+/ATf/dqEG+7GoBgyvPP70n5A1tUGD2/G5j4UtHlHybViZu 0g/NB4wAY6uEtjQeIZ73BVToyapEw2o2ur5ee1IYbBmajsZp6xXiUWhmBEOaqUkZkrRz HYscVh70yQcTSYdCnxKK7iKSlzpJJvDpSzZmmMgiECXOr45SqT6M1T5PteAm3/Gydqa9 7AXQ== X-Forwarded-Encrypted: i=1; AJvYcCVmKAYa/eZXHPTjTdLjouVkB2yv4YnM9Lw+kkPsNUaTihFJglD8AbPgJJ00guNH1OJgJtlRRg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzDn9LrxYQWK9Wq04KWMt7Wu/32ESu0wTpSbiclQCeN2Hz0KTsu mfrgiMXTsaMYZNHhPmLmV5IqWIg6EsrOe9TzlcR4oFa83c9FOBFjFL2p X-Gm-Gg: ASbGncua0YysL0cLD058QrOd5KxFz/+DJWWMhAD+RnQLwAlmUgj+QGS4eBhW8fgJ5Bz ECoye0j3dF3Q2Tpy0TXXWIYlvQGN9r3JNpDCoiH9+KMNZutLVmPpG4SGZivjpnQPc/sjLQjuFgp wnq66npmTVIprGmClod9jJxDD7wRXoAjOXDcJpFpV81t2PmwgTVQFpHmxHO7G+HNKtOeC7G+9/e HUjjCiSE/uo/BfWD/CYI1+Z4mRwB2M2dUImeZ6x1T7WFM/G0GQnRlXh/Z/e+FvoiF3rWPuIgZTC VURpfMvcuBQhHQjnSjFyI5AiScDG0A9mEafrcdK/wTCXGEg+bxCCQgKJGVKbkBt1VCG09PRt6Zy tfmp0G70uN+wAqYk2HdMkxUGDV1g2MJEMK6l45KsmH0I4DrIMIOck1YqRoDtYLBSLt4HVXU9/Gt kiKSX5vISw X-Google-Smtp-Source: AGHT+IEMHoE3/Q7ev2NIiOLm5n93yb9MjOUW9tuouRm4VVmlJEGiPYIQFbib26xdNtHUGwKIfavWGw== X-Received: by 2002:a05:600c:840f:b0:45b:6365:794e with SMTP id 5b1f17b1804b1-45dddecdacemr24045455e9.24.1757176388867; Sat, 06 Sep 2025 09:33:08 -0700 (PDT) Received: from fedora.localnet (2-230-139-124.ip202.fastwebnet.it. [2.230.139.124]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d729a96912sm23013630f8f.8.2025.09.06.09.33.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Sep 2025 09:33:07 -0700 (PDT) From: Vincenzo Pupillo Date: Sat, 06 Sep 2025 18:33:07 +0200 Message-ID: <4835210.vXUDI8C0e8@fedora> In-Reply-To: <867bybfx7d.fsf@gnu.org> References: <86a537fxsy.fsf@gnu.org> <867bybfx7d.fsf@gnu.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) In data sabato 6 settembre 2025 16:54:30 Ora legale dell=E2=80=99Europa cen= trale, Eli=20 Zaretskii ha scritto: > > Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org, > > dmitry@gutov.dev Date: Sat, 06 Sep 2025 17:41:33 +0300 > > From: Eli Zaretskii > >=20 > > > From: Vincenzo Pupillo > > > Cc: sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev, > > >=20 > > > Eli Zaretskii > > >=20 > > > Date: Sat, 06 Sep 2025 16:06:27 +0200 > > >=20 > > > Ciao Eli, after the commit 6c150961fd07e19b6c871d8963d6b9826ec8140f > > > (HEAD) to the master emacs --daemon (with my configuration) now uses > > > 100% of the CPU even if nothing at all is being done in a client. > > > Checking out 6b42b974ceabba8b0215498d4a6eb5048d91514d and recompiling > > > fix the issue. Could the issue be related to this commit on > > > src/process.c?>=20 > > I cannot reproduce this. Please show a recipe starting from how you > > start the daemon and then how you start the client. I tried the na=C3= =AFve > > thing, but 'top' didn't show any 100% CPU consumption by either the > > daemon or the client. >=20 > However, I've just installed something to make that change safer. So > before you post the recipe, please check if the latest master still > exhibits the problematic behavior. Thank you Eli, your latest patch works. Vincenzo From unknown Sun Sep 14 05:04:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 17:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79367 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vincenzo Pupillo Cc: i@fuzy.me, sbaugh@janestreet.com, dmitry@gutov.dev, 79367@debbugs.gnu.org Received: via spool by 79367-submit@debbugs.gnu.org id=B79367.175717841610829 (code B ref 79367); Sat, 06 Sep 2025 17:07:02 +0000 Received: (at 79367) by debbugs.gnu.org; 6 Sep 2025 17:06:56 +0000 Received: from localhost ([127.0.0.1]:37350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuwNM-0002ob-2S for submit@debbugs.gnu.org; Sat, 06 Sep 2025 13:06:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42424) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuwNH-0002oG-AM for 79367@debbugs.gnu.org; Sat, 06 Sep 2025 13:06:52 -0400 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 1uuwN4-0006WM-9V; Sat, 06 Sep 2025 13:06:38 -0400 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=B77lFwhZKInwDCBBLeEw9DKlERXCDIzocGPYACMse44=; b=iTEY1AY7yS9iRmLmhW2U p8OSncGqqmC1EibcbWAL9QM8JFU+GdwKIWMgsBorVbi4Jok0EDoWElStx3gBrO77sOb1NK3R3bBYN 13OuPoxoARi6Xb4RgVw1Phvgvm5MsYLuLIwG2VTraZWmkcGwF2ooHTyO2+JrnjJJwjiCKXhB+MmuV jFORGEIC2CQDvOOQBuRKiyfchpdZ9OVSA8UFeT2pdYUQWUUiEhuOkoEhtDmp0Jei0hdLMYu88lSE8 R6D9VvQ1MvGCg0J7wRXKlP/9TyoelWj/PmlUjLXKeTxtVejs6NjKha3om7IO+B4dijddAwY3qwE91 dleqeBwTD+wStw==; Date: Sat, 06 Sep 2025 20:06:35 +0300 Message-Id: <86v7lvecis.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <4835210.vXUDI8C0e8@fedora> (message from Vincenzo Pupillo on Sat, 06 Sep 2025 18:33:07 +0200) References: <86a537fxsy.fsf@gnu.org> <867bybfx7d.fsf@gnu.org> <4835210.vXUDI8C0e8@fedora> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Vincenzo Pupillo > Cc: i@fuzy.me, sbaugh@janestreet.com, 79367@debbugs.gnu.org, dmitry@gutov.dev > Date: Sat, 06 Sep 2025 18:33:07 +0200 > > > > > Ciao Eli, after the commit 6c150961fd07e19b6c871d8963d6b9826ec8140f > > > > (HEAD) to the master emacs --daemon (with my configuration) now uses > > > > 100% of the CPU even if nothing at all is being done in a client. > > > > Checking out 6b42b974ceabba8b0215498d4a6eb5048d91514d and recompiling > > > > fix the issue. Could the issue be related to this commit on > > > > src/process.c?> > > > I cannot reproduce this. Please show a recipe starting from how you > > > start the daemon and then how you start the client. I tried the naïve > > > thing, but 'top' didn't show any 100% CPU consumption by either the > > > daemon or the client. > > > > However, I've just installed something to make that change safer. So > > before you post the recipe, please check if the latest master still > > exhibits the problematic behavior. > Thank you Eli, your latest patch works. Great, thanks for testing.