GNU bug report logs - #79367
31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t

Previous Next

Package: emacs;

Reported by: Zhengyi Fu <i <at> fuzy.me>

Date: Tue, 2 Sep 2025 06:21:01 UTC

Severity: normal

Found in version 31.0.50

Full log


Message #26 received at 79367 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: i <at> fuzy.me, dmitry <at> gutov.dev, 79367 <at> debbugs.gnu.org
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
 diff-hl-update-async is t
Date: Tue, 02 Sep 2025 17:42:56 +0300
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: Dmitry Gutov <dmitry <at> gutov.dev>,  Eli Zaretskii <eliz <at> gnu.org>,
>    79367 <at> debbugs.gnu.org
> Date: Tue, 02 Sep 2025 09:56:47 -0400
> 
> Zhengyi Fu <i <at> fuzy.me> writes:
> > Spencer Baugh <sbaugh <at> janestreet.com> 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.




This bug report was last modified 7 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.