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 #122 received at 79367 <at> debbugs.gnu.org (full text, mbox):

From: Zhengyi Fu <i <at> fuzy.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: i <at> fuzy.me, Spencer Baugh <sbaugh <at> janestreet.com>, 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: Fri, 05 Sep 2025 14:51:42 +0800
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: i <at> fuzy.me,  79367 <at> debbugs.gnu.org,  dmitry <at> gutov.dev
>> Date: Thu, 04 Sep 2025 15:30:30 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> >> Cc: i <at> fuzy.me,  79367 <at> debbugs.gnu.org,  dmitry <at> gutov.dev
>> >> Date: Thu, 04 Sep 2025 12:41:04 -0400
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> 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.

[Message part 2 (text/plain, inline)]
Thread 1 "emacs" hit Breakpoint 1, die (msg=msg <at> entry=0x55555588fd38 "!fd_callback_info[p->infd].thread", file=file <at> entry=0x555555879464 "process.c", line=line <at> entry=5127) at alloc.c:7302
7302    {
(gdb) bt
#0  die (msg=msg <at> entry=0x55555588fd38 "!fd_callback_info[p->infd].thread", file=file <at> entry=0x555555879464 "process.c", line=line <at> 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 <at> entry=30, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0) at process.c:5989
#3  0x00005555555a3188 in sit_for (timeout=<optimized out>, reading=reading <at> entry=true, display_option=display_option <at> entry=1) at dispnew.c:6978
#4  0x000055555570b8ba in read_char (commandflag=1, map=map <at> entry=0x555556aa02b3, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffd8bb, end_time=end_time <at> entry=0x0)
    at keyboard.c:2925
#5  0x000055555570e164 in read_key_sequence
    (keybuf=keybuf <at> entry=0x7fffffffda10, prompt=prompt <at> entry=0x0, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> 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 <at> entry=0x55555570fcb2 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x555555700325 <cmd_error>)
    at eval.c:1690
#8  0x00005555556f8b3b in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1163
#9  0x00005555557a5aa7 in internal_catch (tag=tag <at> entry=0x118e0, func=func <at> entry=0x5555556f8b14 <command_loop_2>, arg=arg <at> 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=<optimized out>) 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 = <optimized out>
ps = <optimized out>
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' <repeats 36 times>}}
len = 35
count = <optimized out>
args = {0x7fffffffcf84, 0x55555686ace4, 0xa, 0x5724a633450d2100, 0x7fffffffd190, 0x555555a714e0, 0x555555c2a7f0, 0x0, 0x400000000a000000, 0x400000003f000000, 0x7fffffffd1b0}
nargs = <optimized out>
host_format_in = 0x7fffffffd004
host_format_in6 = 0x7fffffffcfe4
procname_format_in = 0x7fffffffcfc4
procname_format_in6 = 0x7fffffffcfa4
procname_format_default = 0x7fffffffcf84
name = <optimized out>
proc = 0x555556bd4c0d
dash = <optimized out>
nl = <optimized out>
host_string = <optimized out>
open_from = <optimized out>
(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 <main_thread+5>, 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}

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.