X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 26 Aug 2025 16:21:02 +0000
Resent-Message-ID: <handler.79318.B.17562252312325 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: 79318 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.17562252312325
(code B ref -1); Tue, 26 Aug 2025 16:21:02 +0000
Received: (at submit) by debbugs.gnu.org; 26 Aug 2025 16:20:31 +0000
Received: from localhost ([127.0.0.1]:56285 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uqwPN-0000bQ-Op
for submit <at> debbugs.gnu.org; Tue, 26 Aug 2025 12:20:31 -0400
Received: from lists.gnu.org ([2001:470:142::17]:59668)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1uqwPH-0000W2-SL
for submit <at> debbugs.gnu.org; Tue, 26 Aug 2025 12:20:26 -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 <sbaugh@HIDDEN>)
id 1uqwOn-0001Wy-C7
for bug-gnu-emacs@HIDDEN; Tue, 26 Aug 2025 12:19:54 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>)
id 1uqwO8-0000ce-Gl
for bug-gnu-emacs@HIDDEN; Tue, 26 Aug 2025 12:19:20 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Tue, 26 Aug 2025 12:19:07 -0400
Message-ID: <iertt1ukqdg.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1756225147;
bh=wh4UuUekuNH6AW7NwufGeV1MI5q63jJ7ZdecUclNm24=;
h=From:To:Subject:Date;
b=BU0s1SazqZFgQfTz/KNT6xl8nj9Oq9cMOSF6En4YiwbQVlmRzxq02T5l5+qM2VGGa
BOEBRGHnAg7N9Cx58pLtwINgbwIUx/PUtV6zD284TTWlBXgKzRI1UGLW05kBgJ1ylC
z1iOS2KGpp7e6JyLOOA1+RET5S7kVVJuJV4hNx0wwGNV0zsuvvU78TKFRsMPMu9tc7
NqWVt3EfyckjHifZjxi+RTimu5Z59Szl2yPHmstL815UW4nn82464+n4MFUoWHuetl
qNUYGKbCFMrQT0CmEZwzt6ZY8ZYdDxmpyCEFdtjCD2bAibL15Wh3RlMtRlbItI16+o
CiyNaQbJD7iXQ==
Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@HIDDEN;
helo=mxout5.mail.janestreet.com
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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.9 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)
repro.el:
(make-thread
(lambda ()
(sleep-for .1)
(signal-process (emacs-pid) 'sigint)))
(sleep-for 100)
emacs -Q -l ./repro.el
Observe Emacs crashes with a segfault while shutting down.
In gdb, the segfault appears to be because current_thread is NULL.
This happens both in 30.2 and on trunk.
bt full:
#0 0x000000000041f32c in Fkill_emacs (arg=arg@entry=make_fixnum(2), restart=restart@entry=XIL(0)) at emacs.c:3002
exit_code = <optimized out>
#1 0x000000000041f482 in terminate_due_to_signal (sig=sig@entry=2, backtrace_limit=backtrace_limit@entry=40) at lisp.h:1226
#2 0x000000000041f8f6 in handle_fatal_signal (sig=sig@entry=2) at sysdep.c:1800
#3 0x0000000000557804 in deliver_process_signal (sig=2, handler=0x41f8eb <handle_fatal_signal>) at sysdep.c:1758
old_errno = 4
on_main_thread = true
#4 0x00007fffefc12970 in <signal handler called> () at /lib64/libpthread.so.0
#5 0x00007fffec134cd9 in pselect () at /lib64/libc.so.6
#6 0x000000000063b1b0 in really_call_select (arg=0x7fffffffbb80) at thread.c:624
sa = 0x7fffffffbb80
self = 0xc77300 <main_thread>
oldset = {
__val = {0, 5631674, 1184, 0, 0, 6023007, 6, 5944137, 0, 5635264, 140736988778981, 8, 140737488337912, 13783008, 140737340983936, 6}
}
#7 0x000000000063bd7e in flush_stack_call_func (arg=0x7fffffffbb80, func=0x63b160 <really_call_select>) at lisp.h:4509
sa = {
func = 0x419450 <pselect@plt>,
max_fds = 6,
rfds = 0x7fffffffbc70,
wfds = 0x7fffffffbcf0,
efds = 0x0,
timeout = 0x7fffffffc280,
sigmask = 0x0,
result = -135497884
}
#8 0x000000000063bd7e in thread_select (func=<optimized out>, max_fds=max_fds@entry=6, rfds=rfds@entry=0x7fffffffbc70, wfds=wfds@entry=0x7fffffffbcf0, efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffc280, sigmask=0x0) at thread.c:656
sa = {
func = 0x419450 <pselect@plt>,
max_fds = 6,
rfds = 0x7fffffffbc70,
wfds = 0x7fffffffbcf0,
efds = 0x0,
timeout = 0x7fffffffc280,
sigmask = 0x0,
result = -135497884
}
#9 0x0000000000668a3e in xg_select (fds_lim=6, rfds=rfds@entry=0x7fffffffc3f0, wfds=wfds@entry=0x7fffffffc470, efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffc280, sigmask=sigmask@entry=0x0) at xgselect.c:184
all_rfds = {
fds_bits = {32, 0 <repeats 15 times>}
}
all_wfds = {
fds_bits = {0 <repeats 16 times>}
}
tmo = {
tv_sec = 0,
tv_nsec = 0
}
tmop = 0x7fffffffc280
context = 0xdb81a0
have_wfds = <optimized out>
gfds_buf = {{
fd = 5,
events = 1,
revents = 0
}, {
fd = 15393381,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 48,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 6,
events = 0,
revents = 0
}, {
fd = 2,
events = 0,
revents = 0
}, {
fd = 2,
events = 0,
revents = 0
}, {
fd = 2,
events = 0,
revents = 0
}, {
fd = 2,
events = 0,
revents = 0
}, {
fd = -334913767,
events = 32767,
revents = 0
}, {
fd = 15040436,
events = 0,
revents = 0
}, {
fd = -331543520,
events = 32767,
revents = 0
}, {
fd = 6400,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 7,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = -1089891930,
events = 65152,
revents = 22775
}, {
fd = 13945992,
events = 0,
revents = 0
}, {
fd = 6448,
events = 0,
revents = 0
}, {
fd = -440,
events = 65535,
revents = 65535
}, {
fd = 100,
events = 0,
revents = 0
}, {
fd = 103,
events = 148,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 103,
events = 119,
revents = 0
}, {
fd = 12,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 124,
events = 111,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = -331543616,
events = 32767,
revents = 0
}, {
fd = 6400,
events = 0,
revents = 0
}, {
fd = -440,
events = 65535,
revents = 65535
}, {
fd = 25,
events = 0,
revents = 0
}, {
fd = 80,
events = 0,
revents = 0
}, {
fd = 25,
events = 0,
revents = 0
}, {
fd = -334909086,
events = 32767,
revents = 0
}, {
fd = 6400,
events = 0,
revents = 0
}, {
fd = 6400,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 5873064,
events = 0,
revents = 0
}, {
fd = 3840,
events = 0,
revents = 0
}, {
fd = 0,
events = 24,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 25,
events = 0,
revents = 0
}, {
fd = 15398112,
events = 0,
revents = 0
}, {
fd = 5873287,
events = 0,
revents = 0
}, {
fd = 3840,
events = 0,
revents = 0
}, {
fd = 15398096,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 4357902,
events = 0,
revents = 0
}, {
fd = 15397616,
events = 0,
revents = 0
}, {
fd = 321,
events = 0,
revents = 0
}, {
fd = 15397600,
events = 0,
revents = 0
}, {
fd = 25,
events = 0,
revents = 0
}, {
fd = 336,
events = 0,
revents = 0
}, {
fd = -334906405,
events = 32767,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = -331543616,
events = 32767,
revents = 0
}, {
fd = -511466344,
events = 25,
revents = 0
}, {
fd = 321,
events = 0,
revents = 0
}, {
fd = 321,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 25,
events = 0,
revents = 0
}, {
fd = 80,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 5872976,
events = 0,
revents = 0
}, {
fd = 80,
events = 25,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 25,
events = 0,
revents = 0
}, {
fd = 14523552,
events = 0,
revents = 0
}, {
fd = 80,
events = 25,
revents = 0
}, {
fd = 4381164,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 4830954,
events = 0,
revents = 0
}, {
fd = 15393376,
events = 0,
revents = 0
}, {
fd = 15393376,
events = 2,
revents = 0
}, {
fd = -16220,
events = 32767,
revents = 0
}, {
fd = 15393376,
events = 0,
revents = 0
}, {
fd = 80,
events = 0,
revents = 0
}, {
fd = 80,
events = 0,
revents = 0
}, {
fd = 25,
events = 0,
revents = 0
}, {
fd = 14523552,
events = 0,
revents = 0
}, {
fd = 80,
events = 0,
revents = 0
}, {
fd = 4409751,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 5,
events = 0,
revents = 0
}, {
fd = 2,
events = 0,
revents = 0
}, {
fd = 538976288,
events = 80,
revents = 0
}, {
fd = 25,
events = 80,
revents = 0
}, {
fd = 2,
events = 8224,
revents = 8224
}, {
fd = 24,
events = 0,
revents = 0
}, {
fd = 1,
events = 25,
revents = 0
}, {
fd = 80,
events = 1,
revents = 0
}, {
fd = 80,
events = 0,
revents = 256
}, {
fd = 0,
events = 80,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 25,
events = 25,
revents = 0
}, {
fd = 6457486,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 5510312,
events = 0,
revents = 0
}, {
fd = -16048,
events = 32767,
revents = 0
}, {
fd = 13783008,
events = 65533,
revents = 65535
}, {
fd = -512860104,
events = 32767,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 37392,
events = 0,
revents = 0
}, {
fd = 14523557,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 5,
events = 5,
revents = 0
}, {
fd = 37392,
events = 0,
revents = 0
}, {
fd = 14523557,
events = 0,
revents = 0
}, {
fd = 48,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = 0,
events = 0,
revents = 0
}, {
fd = 1,
events = 0,
revents = 0
}, {
fd = -15984,
events = 32767,
revents = 0
}, {
fd = -334485062,
events = 32767,
revents = 0
}}
gfds = 0x7fffffffbd70
gfds_size = <optimized out>
n_gfds = <optimized out>
retval = 0
our_fds = 0
max_fds = <optimized out>
i = <optimized out>
nfds = <optimized out>
tmo_in_millisec = -1
must_free = <optimized out>
need_to_dispatch = <optimized out>
#10 0x00000000006191a3 in wait_reading_process_output (time_limit=time_limit@entry=100, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=0, do_display=do_display@entry=false, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5711
tls_nfds = 0
tls_available = {
fds_bits = {0 <repeats 16 times>}
}
process_skipped = <optimized out>
wrapped = <optimized out>
channel_start = <optimized out>
child_fd = <optimized out>
last_read_channel = -1
channel = <optimized out>
nfds = <optimized out>
Available = {
fds_bits = {0 <repeats 16 times>}
}
Writeok = {
fds_bits = {0 <repeats 16 times>}
}
check_write = true
check_delay = <optimized out>
no_avail = false
xerrno = 4
proc = <optimized out>
timeout = {
tv_sec = 99,
tv_nsec = 999925830
}
end_time = <optimized out>
timer_delay = <optimized out>
got_output_end_time = {
tv_sec = 0,
tv_nsec = -1
}
wait = TIMEOUT
got_some_output = -1
prev_wait_proc_nbytes_read = 0
retry_for_async = <optimized out>
now = <optimized out>
#11 0x000000000042788b in Fsleep_for (seconds=<optimized out>, milliseconds=<optimized out>) at lisp.h:1192
t = {
tv_sec = 100,
tv_nsec = 0
}
tend = {
tv_sec = 1756225164,
tv_nsec = 695603177
}
duration = <optimized out>
#12 0x00000000005c1f2e in eval_sub (form=<optimized out>) at lisp.h:2243
i = <optimized out>
maxargs = 2
args_left = XIL(0)
numargs = 1
original_fun = <optimized out>
original_args = XIL(0x7ffff73ae593)
count = {
bytes = 1024
}
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {make_fixnum(100), XIL(0), XIL(0x7fffffffc748), XIL(0x400), make_fixnum(0), XIL(0x400), make_fixnum(0), XIL(0x7fffffffc750)}
#13 0x00000000005ea19a in readevalloop_eager_expand_eval (val=<optimized out>, macroexpand=XIL(0xb340)) at lisp.h:1192
#14 0x00000000005f0dbf in readevalloop (readcharfun=XIL(0xe57515), infile0=0x0, sourcename=XIL(0xe213f4), printflag=false, unibyte=<optimized out>, readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2548
c = <optimized out>
val = XIL(0x7ffff73ae583)
b = <optimized out>
continue_reading_p = true
lex_bound = <optimized out>
whole_buffer = true
first_sexp = <optimized out>
macroexpand = XIL(0xb340)
#15 0x00000000005f2070 in Feval_buffer (buffer=<optimized out>, printflag=XIL(0), filename=XIL(0xe213f4), unibyte=XIL(0), do_allow_print=<optimized out>) at lisp.h:1488
tem = XIL(0)
buf = XIL(0xe57515)
#16 0x00007ffff5f1a59e in F6c6f61642d776974682d636f64652d636f6e76657273696f6e_load_with_code_conversion_0 () at /usr/local/home/sbaugh/src/emacs/emacs-30/src/../native-lisp/30.1.90-04e012b0/preloaded/mule-0685467c-3b823856.eln
#17 0x00000000005beba0 in Ffuncall (nargs=nargs@entry=5, args=args@entry=0x7fffffffcaa0) at eval.c:3097
val = <optimized out>
#18 0x00000000005f1879 in Fload (file=XIL(0xe210a4), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=<optimized out>, must_suffix=<optimized out>) at lisp.h:1488
val = <optimized out>
stream = 0x0
fd = 5
found = XIL(0xe213f4)
efound = <optimized out>
hist_file_name = <optimized out>
newer = false
compiled = false
handler = <optimized out>
fmode = 0x6b41e7 "r"
version = 0
no_native = false
is_module = false
is_native_elisp = false
found_eff = <optimized out>
is_elc = false
input = {
stream = 0xeed314,
lookahead = -92 '\244',
buf = "\020\342\000"
}
#19 0x00007ffff57d56bc in F636f6d6d616e642d6c696e652d31_command_line_1_0 () at /usr/local/home/sbaugh/src/emacs/emacs-30/src/../native-lisp/30.1.90-04e012b0/preloaded/startup-1d646357-21c0c8b9.eln
#20 0x00000000005beba0 in Ffuncall (nargs=2, args=0x7fffffffd080) at eval.c:3097
val = <optimized out>
#21 0x00007ffff57cd3af in F636f6d6d616e642d6c696e65_command_line_0 () at /usr/local/home/sbaugh/src/emacs/emacs-30/src/../native-lisp/30.1.90-04e012b0/preloaded/startup-1d646357-21c0c8b9.eln
#22 0x00000000005beba0 in Ffuncall (nargs=1, args=0x7fffffffd158) at eval.c:3097
val = <optimized out>
#23 0x00007ffff57c8bfb in F6e6f726d616c2d746f702d6c6576656c_normal_top_level_0 () at /usr/local/home/sbaugh/src/emacs/emacs-30/src/../native-lisp/30.1.90-04e012b0/preloaded/startup-1d646357-21c0c8b9.eln
#24 0x00000000005c2012 in eval_sub (form=<optimized out>) at lisp.h:2243
i = 0
maxargs = <optimized out>
args_left = XIL(0)
numargs = 0
original_fun = <optimized out>
original_args = XIL(0)
count = {
bytes = 128
}
fun = <optimized out>
val = <optimized out>
funcar = <optimized out>
argvals = {XIL(0xffffffffffffffff), XIL(0x7fffffffd3b4), XIL(0x7fffffffd3e8), make_fixnum(35184288361560), XIL(0xc77300), XIL(0xe1bb40), XIL(0x7ffff73deb43), make_fixnum(1504411)}
#25 0x00000000005c3b0f in Feval (form=XIL(0x7fffe210eaa3), lexical=lexical@entry=XIL(0x30)) at eval.c:2466
#26 0x0000000000537edb in top_level_2 () at lisp.h:1192
res = <optimized out>
#27 0x00000000005bd532 in internal_condition_case (bfun=bfun@entry=0x537e90 <top_level_2>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x53f140 <cmd_error>) at eval.c:1617
val = <optimized out>
c = 0xe1bb40
#28 0x0000000000539a02 in top_level_1 (ignore=ignore@entry=XIL(0)) at lisp.h:1192
#29 0x00000000005bd461 in internal_catch (tag=tag@entry=XIL(0x122d0), func=func@entry=0x5399e0 <top_level_1>, arg=arg@entry=XIL(0)) at eval.c:1296
val = <optimized out>
c = 0xef0e00
#30 0x0000000000537dbb in command_loop () at lisp.h:1192
#31 0x000000000053ecf6 in recursive_edit_1 () at keyboard.c:754
val = <optimized out>
#32 0x000000000053f084 in Frecursive_edit () at keyboard.c:837
buffer = <optimized out>
#33 0x00000000004267a7 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:2646
stack_bottom_variable = 0xc4acf64ff28ad800
old_argc = <optimized out>
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
dump_mode = <optimized out>
skip_args = 1
temacs = 0x0
attempt_load_pdump = <optimized out>
only_version = <optimized out>
rlim = {
rlim_cur = 10022912,
rlim_max = 18446744073709551615
}
lc_all = <optimized out>
sockfd = -1
module_assertions = <optimized out>
In GNU Emacs 30.1.90 (build 9, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.12, Xaw scroll bars) of 2025-08-14 built on
igm-qws-u22796a
Repository revision: 6adc26ffa74aedbd1cfa9a1ee72073ebccea2b96
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Rocky Linux 8.10 (Green Obsidian)
Configured using:
'configure --with-x-toolkit=lucid --without-gpm --without-gconf
--without-selinux --without-imagemagick --with-modules --with-gif=no
--with-cairo --with-rsvg --without-compress-install --with-tree-sitter
--with-native-compilation=aot
PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/'
Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: Spencer Baugh <sbaugh@HIDDEN> Subject: bug#79318: Acknowledgement (31.1.90; Threads + receiving a signal causes a segfault) Message-ID: <handler.79318.B.17562252312325.ack <at> debbugs.gnu.org> References: <iertt1ukqdg.fsf@HIDDEN> X-Gnu-PR-Message: ack 79318 X-Gnu-PR-Package: emacs Reply-To: 79318 <at> debbugs.gnu.org Date: Tue, 26 Aug 2025 16:21:03 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-gnu-emacs@HIDDEN If you wish to submit further information on this problem, please send it to 79318 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 79318: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D79318 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 26 Aug 2025 18:46:01 +0000
Resent-Message-ID: <handler.79318.B79318.175623392930478 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Spencer Baugh <sbaugh@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Cc: 79318 <at> debbugs.gnu.org
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.175623392930478
(code B ref 79318); Tue, 26 Aug 2025 18:46:01 +0000
Received: (at 79318) by debbugs.gnu.org; 26 Aug 2025 18:45:29 +0000
Received: from localhost ([127.0.0.1]:56711 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uqyfh-0007vU-Am
for submit <at> debbugs.gnu.org; Tue, 26 Aug 2025 14:45:29 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:40218)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uqyfd-0007vF-5c
for 79318 <at> debbugs.gnu.org; Tue, 26 Aug 2025 14:45: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 <eliz@HIDDEN>)
id 1uqyfT-0008TC-3E; Tue, 26 Aug 2025 14:45:15 -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=AY1ZVSReYX8YGpsYDWchphuhjEHWsXuKNgbCRSJHk7A=; b=iwAFa7itt2gY
TtRDEQaq6BVz01/Z9uzcRT5dmQdX3/teseTmPYj7nm00P5LVG2blJPwdZ/iB02Wu5fc3qp574Zk4+
FCYZ1X6iqS6E3B2ZHbmRLQtyGCt5sv9tYkxmeqaZw7EVScm6q21RCy9FAdQO4dlW59PumcBRoh6WI
yhxJUEq41l+289Fq/PHANaRubE1CCUUtSAoh1TuN1u+OveN3yuCHyQtYLJRq5WVR+mparetBlSHDY
55TQXZ5Lj5GbYeSfMKbCJJsGCELYatOjTsJLh/UuFIcPACGqIlPSCnO6+KbAuj9Nv0pG4ZLGfuHPt
KSMNQfiYRv54tgV91b0z5Q==;
Date: Tue, 26 Aug 2025 21:45:03 +0300
Message-Id: <867bypvs5s.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <iertt1ukqdg.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
References: <iertt1ukqdg.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Tue, 26 Aug 2025 12:19:07 -0400
> From: Spencer Baugh via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
>
> repro.el:
>
> (make-thread
> (lambda ()
> (sleep-for .1)
> (signal-process (emacs-pid) 'sigint)))
> (sleep-for 100)
>
> emacs -Q -l ./repro.el
>
> Observe Emacs crashes with a segfault while shutting down.
I don't see a segfault in your backtrace, only a shutdown due to
SIGINT (which is a fatal signal in the configuration you ran -- Paul,
am I right?)
> In gdb, the segfault appears to be because current_thread is NULL.
Please show the backtrace from the segfault. What you posted was a
SIGINT that caused shutdown, which seems to be normal (in the GUI
session on X). On Windows and in -nw session, there's no shutdown.
Why is this case interesting? When delivering a fatal signal to the
own Emacs process, a fatal error and a shutdown should not come as a
surprise, right? Or what am I missing?
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 26 Aug 2025 19:24:01 +0000
Resent-Message-ID: <handler.79318.B79318.17562362114842 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 79318 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.17562362114842
(code B ref 79318); Tue, 26 Aug 2025 19:24:01 +0000
Received: (at 79318) by debbugs.gnu.org; 26 Aug 2025 19:23:31 +0000
Received: from localhost ([127.0.0.1]:56771 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uqzGU-0001G1-Mf
for submit <at> debbugs.gnu.org; Tue, 26 Aug 2025 15:23:31 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60659)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1uqzGR-0001Fh-CE
for 79318 <at> debbugs.gnu.org; Tue, 26 Aug 2025 15:23:27 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <867bypvs5s.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 26 Aug
2025 21:45:03 +0300")
References: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
Date: Tue, 26 Aug 2025 15:23:20 -0400
Message-ID: <ierqzwxlwev.fsf@HIDDEN>
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=1756236200;
bh=Z9fGkWrslddwNc8BIveEPf/h9hi/s2VTQmkhptz5w1M=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=L8rqAknglBXopiWVFP1hsviL4u8xhAzIRp4/hNZ2YCjRSlhJbdjT0yh9b9t2xWpmZ
YhCOqT/BlC9ts1AAUygEzs0UV+tjzeWmeJY0fJ/VsQGefgnbrEmj1872SPuw55dWUi
2ZIDbu/A41BFpnqzePZdk7vnRek/0jNqw41MwdDTQSFNxaS96uLU0H3bsd0mXR7KQ+
B5J3wAExyxVOCohG3hY6+9AvoAENIWBh4rvae9jeHciArGzuP5FwTPYFk7S5ISD1JO
xqY6QHw0But1158jNDAAkIeyTWV4b0R5IfZFN0Ueg7XjVHAT9lK5AY+WCwDyyH1WBc
exOOf8GpyDrIA==
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Eli Zaretskii <eliz@HIDDEN> writes:
>> Date: Tue, 26 Aug 2025 12:19:07 -0400
>> From: Spencer Baugh via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>>
>> repro.el:
>>
>> (make-thread
>> (lambda ()
>> (sleep-for .1)
>> (signal-process (emacs-pid) 'sigint)))
>> (sleep-for 100)
>>
>> emacs -Q -l ./repro.el
>>
>> Observe Emacs crashes with a segfault while shutting down.
>
> I don't see a segfault in your backtrace, only a shutdown due to
> SIGINT (which is a fatal signal in the configuration you ran -- Paul,
> am I right?)
The backtrace is of the point at which there's a segfault. It happens
during shutdown.
>> In gdb, the segfault appears to be because current_thread is NULL.
>
> Please show the backtrace from the segfault.
I did.
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 02:27:02 +0000
Resent-Message-ID: <handler.79318.B79318.175626161323809 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: 79318 <at> debbugs.gnu.org, eggert@HIDDEN
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.175626161323809
(code B ref 79318); Wed, 27 Aug 2025 02:27:02 +0000
Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 02:26:53 +0000
Received: from localhost ([127.0.0.1]:57992 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ur5sC-0006Bw-TF
for submit <at> debbugs.gnu.org; Tue, 26 Aug 2025 22:26:53 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:58966)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1ur5s9-0006Bg-8E
for 79318 <at> debbugs.gnu.org; Tue, 26 Aug 2025 22:26:51 -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 <eliz@HIDDEN>)
id 1ur5s0-0003Fj-LQ; Tue, 26 Aug 2025 22:26:40 -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=00/eoRKrh2SovoytYnIWU0JeEaKBlYGvq39oaAm2aGw=; b=H3vJkzp2W/77
T7D7+cGV/NEdxmsYHJiuXNi4VlCsdc4ykdUKO4rE0l4jNbrP2R6EihIbbXrKhmN/uJfTi3Sxg3oa/
V9S9/G0GOOsvOz64ESvIcfu7P7kHfWhgvhGv6G0a7wwJPrk0m7CRuRS/tkg+Sascx30BVbQexWNLg
fAbah+OQ6pcD++G0taqi/toSfiaNvQmUO0R1O0WfAEOQBpoJFeg3nG1gbNXI3nZt2aOcr11TZPmPJ
Abi7Q7mD1Hkn1aLVR6mrr9ZbgOl6QxzVL+DgTiHdi3jKIwGX5rh09ZiJjIV4SW8+CJ0lgLbLEl3IQ
eNhXGtK3GOCKmGfnVssiYA==;
Date: Wed, 27 Aug 2025 05:26:37 +0300
Message-Id: <864ittv6si.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <ierqzwxlwev.fsf@HIDDEN> (message from Spencer Baugh on
Tue, 26 Aug 2025 15:23:20 -0400)
References: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
<ierqzwxlwev.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Spencer Baugh <sbaugh@HIDDEN>
> Cc: Paul Eggert <eggert@HIDDEN>, 79318 <at> debbugs.gnu.org
> Date: Tue, 26 Aug 2025 15:23:20 -0400
>
> Eli Zaretskii <eliz@HIDDEN> writes:
>
> >> Date: Tue, 26 Aug 2025 12:19:07 -0400
> >> From: Spencer Baugh via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> >>
> >>
> >> repro.el:
> >>
> >> (make-thread
> >> (lambda ()
> >> (sleep-for .1)
> >> (signal-process (emacs-pid) 'sigint)))
> >> (sleep-for 100)
> >>
> >> emacs -Q -l ./repro.el
> >>
> >> Observe Emacs crashes with a segfault while shutting down.
> >
> > I don't see a segfault in your backtrace, only a shutdown due to
> > SIGINT (which is a fatal signal in the configuration you ran -- Paul,
> > am I right?)
>
> The backtrace is of the point at which there's a segfault. It happens
> during shutdown.
>
> >> In gdb, the segfault appears to be because current_thread is NULL.
> >
> > Please show the backtrace from the segfault.
>
> I did.
Such a backtrace should say that the process was hit by SIGSEGV.
There was no such part in the backtrace you have shown.
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 05:08:01 +0000
Resent-Message-ID: <handler.79318.B79318.175627126232578 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 79318 <at> debbugs.gnu.org, eggert@HIDDEN
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.175627126232578
(code B ref 79318); Wed, 27 Aug 2025 05:08:01 +0000
Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 05:07:42 +0000
Received: from localhost ([127.0.0.1]:58365 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ur8Np-0008TM-KW
for submit <at> debbugs.gnu.org; Wed, 27 Aug 2025 01:07:42 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:40135)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1ur8Nk-0008Sp-JH
for 79318 <at> debbugs.gnu.org; Wed, 27 Aug 2025 01:07:38 -0400
Received: from mail-ej1-f71.google.com ([209.85.218.71])
by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128)
(Exim 4.98.2) id 1ur8Nd-00000008y2d-0y9u for 79318 <at> debbugs.gnu.org;
Wed, 27 Aug 2025 01:07:29 -0400
Received: by mail-ej1-f71.google.com with SMTP id
a640c23a62f3a-afcb733834bso536997266b.0
for <79318 <at> debbugs.gnu.org>; Tue, 26 Aug 2025 22:07:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=janestreet.com; s=google; t=1756271248; x=1756876048; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=4yDih4t9Rk7KWWhQB1f9FInBzBXCIhvD47pdCgba/OI=;
b=AIBcYRTbboTGFn314jyZasABMm9xRwjQe8o5vdrRJAUGBIRmLRnf0BX8IsmkoTywBh
yt8HZj2vRRQ4yv9jZ4bcUwHl+BJvrhwzhtjO0rmPArWyQ2c5TiffHG7TP4/mTTkms4iK
itfAPVnVx/iIetAccD5+37L8iN6kB4LSWz+pM=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1756271249;
bh=4yDih4t9Rk7KWWhQB1f9FInBzBXCIhvD47pdCgba/OI=;
h=References:In-Reply-To:From:Date:Subject:To:Cc;
b=agc13nqMWh82B3c1C1AObHbHy/UIZOO1QA7vSAMEKMmZrVgN8/u7g6ybqyAx1L7Yw
Ek7HKBqpOI6GY/Ltn5jVT3qQH0eTMeMc5r8fJCTnYCaR1mDsG40a+6GZc/xXQBfugA
2PvAyaV7yB845CCugrKHWU/Ftl7sq7MLwvFVxdlG2I778FVSP7NuLM91PYOKa4hE7s
QubtvvjAkhBrm0/6TnfhSC0P1sFr+T1Cr/Z/j6P50BYo02EQhWCuhl/zAUcErrLTh+
/eG/wJ2GUAPi0ODUsNuaA1Z1WBScO/rFLXSqJ19ISurb//5PAQZraHOeuGzSza4Cs5
9R3JHzaHpcVYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1756271248; x=1756876048;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=4yDih4t9Rk7KWWhQB1f9FInBzBXCIhvD47pdCgba/OI=;
b=moBh4vM3v/XRkcWKegVao0d6Mcon8+qYI5xNOvUK+96nxxQyYiALfaBYLGjPk1hZi0
+VnDdf4cQXtcBVNVq8ylUgBJ2h7xNYOU5HCIrQwFRKtudP2QleVYmmmC1iXHn6gphF2L
MgMoJ26ml6xswO3b6vELHxsQ7z0+lFczhvPYElLOx92mutg7Dww/Y3hYmslglnPGH3AZ
SI973PJ0nfqJoEz+hATQajHSul+gknZ+YVQRW5h5B87PZRN1uelKjxnw+dMrPDnYH8xT
unY8hWXATU0MY6Lg5g68PMoUhFWYfKSqAgNKY/3OleHiUdmzU0o54j4fReeMXWH6afd6
IFrw==
X-Forwarded-Encrypted: i=1;
AJvYcCXx3Py9Z9bGKt8/So9zljyc417k/X+D9qL2uk3AjcCsoBex/IruLhHroWxdOjZySvIhUfMg0Q==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxixZlm+u2zuG87r1sxOQhGKfjH3D5SOcwkW+tBJ7VCLAHjW+MJ
PdC2LtLV+FPHwNNcNJ5Keuiu834BdlK1WeM9Qjw5hTSH6h0gjFm1kGByLbERFd+KPETFAYfD2/Z
KvNGz+5eGVCVbRq19JlN1qTXO+Dw3zgWfA88yRfixU9/HdXoGCwZbarjhmjd6BM7UBdSe9csORC
ASgTnZS/hiwL6i7b6Wy33otd495FG3KQ==
X-Gm-Gg: ASbGncsu+zCBdxPk/98U5n7jJoaH58MCjjMMUnfcz4rpvi88L6TfEV/Gps4AzNaBARA
FPUpd6oV42kQreK9FhQ+BgHSSBuJVk++KZGA9XcLFeunNotbngd9cHv3hfPjBH1pByc3u6gQ7v7
TEZ/Jc5OchtXVtHYUU5oDz
X-Received: by 2002:a17:907:3e9e:b0:af9:c1f6:19de with SMTP id
a640c23a62f3a-afe28f7b1dcmr1620994966b.13.1756271248566;
Tue, 26 Aug 2025 22:07:28 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IGe9TKzVQzjB+eQCXT7c8yrNZahIN3fsUWfD8dN/8iBieE4/UVwVfZ32Xf1ZL6+bG++qSwRr7fQizGuYRSp1YU=
X-Received: by 2002:a17:907:3e9e:b0:af9:c1f6:19de with SMTP id
a640c23a62f3a-afe28f7b1dcmr1620993466b.13.1756271248176; Tue, 26 Aug 2025
22:07:28 -0700 (PDT)
MIME-Version: 1.0
References: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
<ierqzwxlwev.fsf@HIDDEN> <864ittv6si.fsf@HIDDEN>
In-Reply-To: <864ittv6si.fsf@HIDDEN>
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Wed, 27 Aug 2025 01:07:17 -0400
X-Gm-Features: Ac12FXwnYNOClu7l3GusuEUwB8Zy7sUNxj4o_14-bYHWsQp3w-HnM5qyoduOhIg
Message-ID: <CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000e08934063d51c3ec"
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--000000000000e08934063d51c3ec
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Aug 26, 2025, 10:26=E2=80=AFPM Eli Zaretskii <eliz@HIDDEN> wrote:
> > From: Spencer Baugh <sbaugh@HIDDEN>
> > Cc: Paul Eggert <eggert@HIDDEN>, 79318 <at> debbugs.gnu.org
> > Date: Tue, 26 Aug 2025 15:23:20 -0400
> >
> > Eli Zaretskii <eliz@HIDDEN> writes:
> >
> > >> Date: Tue, 26 Aug 2025 12:19:07 -0400
> > >> From: Spencer Baugh via "Bug reports for GNU Emacs,
> > >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> > >>
> > >>
> > >> repro.el:
> > >>
> > >> (make-thread
> > >> (lambda ()
> > >> (sleep-for .1)
> > >> (signal-process (emacs-pid) 'sigint)))
> > >> (sleep-for 100)
> > >>
> > >> emacs -Q -l ./repro.el
> > >>
> > >> Observe Emacs crashes with a segfault while shutting down.
> > >
> > > I don't see a segfault in your backtrace, only a shutdown due to
> > > SIGINT (which is a fatal signal in the configuration you ran -- Paul,
> > > am I right?)
> >
> > The backtrace is of the point at which there's a segfault. It happens
> > during shutdown.
> >
> > >> In gdb, the segfault appears to be because current_thread is NULL.
> > >
> > > Please show the backtrace from the segfault.
> >
> > I did.
>
> Such a backtrace should say that the process was hit by SIGSEGV.
> There was no such part in the backtrace you have shown.
>
My version of gdb does not.
>
--000000000000e08934063d51c3ec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 26, 2025, 10:26=E2=
=80=AFPM Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>=
> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: Spencer Baug=
h <<a href=3D"mailto:sbaugh@HIDDEN" target=3D"_blank" rel=3D"nor=
eferrer">sbaugh@HIDDEN</a>><br>
> Cc: Paul Eggert <<a href=3D"mailto:eggert@HIDDEN" target=3D"_b=
lank" rel=3D"noreferrer">eggert@HIDDEN</a>>,=C2=A0 <a href=3D"mailt=
o:79318 <at> debbugs.gnu.org" target=3D"_blank" rel=3D"noreferrer">79318@debbugs=
.gnu.org</a><br>
> Date: Tue, 26 Aug 2025 15:23:20 -0400<br>
> <br>
> Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank" re=
l=3D"noreferrer">eliz@HIDDEN</a>> writes:<br>
> <br>
> >> Date: Tue, 26 Aug 2025 12:19:07 -0400<br>
> >> From:=C2=A0 Spencer Baugh via "Bug reports for GNU Emacs=
,<br>
> >>=C2=A0 the Swiss army knife of text editors" <<a href=
=3D"mailto:bug-gnu-emacs@HIDDEN" target=3D"_blank" rel=3D"noreferrer">bug-=
gnu-emacs@HIDDEN</a>><br>
> >> <br>
> >> <br>
> >> repro.el:<br>
> >> <br>
> >> (make-thread<br>
> >>=C2=A0 (lambda ()<br>
> >>=C2=A0 =C2=A0 (sleep-for .1)<br>
> >>=C2=A0 =C2=A0 (signal-process (emacs-pid) 'sigint)))<br>
> >> (sleep-for 100)<br>
> >> <br>
> >> emacs -Q -l ./repro.el<br>
> >> <br>
> >> Observe Emacs crashes with a segfault while shutting down.<br=
>
> ><br>
> > I don't see a segfault in your backtrace, only a shutdown due=
to<br>
> > SIGINT (which is a fatal signal in the configuration you ran -- P=
aul,<br>
> > am I right?)<br>
> <br>
> The backtrace is of the point at which there's a segfault.=C2=A0 I=
t happens<br>
> during shutdown.<br>
> <br>
> >> In gdb, the segfault appears to be because current_thread is =
NULL.<br>
> ><br>
> > Please show the backtrace from the segfault.<br>
> <br>
> I did.<br>
<br>
Such a backtrace should say that the process was hit by SIGSEGV.<br>
There was no such part in the backtrace you have shown.<br></blockquote></d=
iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">My version of gdb do=
es not.</div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_contai=
ner"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
--000000000000e08934063d51c3ec--
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 12:30:02 +0000
Resent-Message-ID: <handler.79318.B79318.17562977999478 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: eggert@HIDDEN, Spencer Baugh <sbaugh@HIDDEN>
Cc: 79318 <at> debbugs.gnu.org
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.17562977999478
(code B ref 79318); Wed, 27 Aug 2025 12:30:02 +0000
Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 12:29:59 +0000
Received: from localhost ([127.0.0.1]:59935 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1urFHq-0002So-7M
for submit <at> debbugs.gnu.org; Wed, 27 Aug 2025 08:29:58 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:43194)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1urFHk-0002SL-Fb
for 79318 <at> debbugs.gnu.org; Wed, 27 Aug 2025 08:29: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 <eliz@HIDDEN>)
id 1urFHZ-0005Bi-Ms; Wed, 27 Aug 2025 08:29:41 -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=2QVwHIPSs4Wld96+kzTqEqo8Gr2CRMIEIGYube9pl0s=; b=IHJw1h1YLBT6
wmcvaYS2Gy1I1X88Vlcg1YOJttAghNLgxvDGI0lxVIwPtEcCYhqUACZLko+ph16wTYP/TEVXqtC8B
43Af72dfuJjMhvW7O+7C3AzQOtyS/tSyFqYnl19UDYk1WE93xFg/qGuTCCcgliIAlUYGPUTZ0zYgL
GTE4O4zbAi82TQPTwwWYZkNW1klbwaoezNAOeEDIH+VH/f6m1z1Q5XfvgAtCWHphaO6s9edgwl6na
/NE3NUKDF/pseTtAO1RDKgPlRFPQOY6zDbjOJH6PrxcC+N6fYdVU630wDqTFp+EjtpTqQaAJiN7Yc
ZAbtSJfG2ax4jr9tnclb9w==;
Date: Wed, 27 Aug 2025 15:29:35 +0300
Message-Id: <86qzwxt0b4.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
(message from Spencer Baugh on Wed, 27 Aug 2025 01:07:17 -0400)
References: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
<ierqzwxlwev.fsf@HIDDEN> <864ittv6si.fsf@HIDDEN>
<CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Spencer Baugh <sbaugh@HIDDEN>
> Date: Wed, 27 Aug 2025 01:07:17 -0400
> Cc: eggert@HIDDEN, 79318 <at> debbugs.gnu.org
>
> > > Please show the backtrace from the segfault.
> >
> > I did.
>
> Such a backtrace should say that the process was hit by SIGSEGV.
> There was no such part in the backtrace you have shown.
>
> My version of gdb does not.
OK, never mind, that.
I think this bug report raises a much more general issue than what the
recipe shows: what happens when a Lisp thread gets delivered a fatal
signal when it doesn't own the global lock?
This could happen in at least two cases:
. the signal is delivered to the main thread (as AFAIU it happens on
GNU/Linux and some other systems) when the current thread is some
other thread
. the signal is delivered to the main thread while the main thread is
stuck in some wait before it obtained the global lock, and the
other threads all exited (like in the scenario you presented)
The important aspect here is that the signal handler runs in the
context of a thread that doesn't have the global lock, so it cannot
run Lisp or the Lisp machine safely. However, calling kill-emacs, as
part of an attempt to shut down Emacs in an orderly fashion, can and
does run Lisp.
AFAICT, we don't currently have a solution for this situation.
We could do several things:
. do nothing, and let kill-emacs crash if it must -- after all, the
attempt at an orderly shut down is known to fail in some cases
. override attempt-orderly-shutdown-on-fatal-signal in such cases
and just call shutdown_emacs (losing some of the session as
result)
. somehow attempt to force the thread holding the global lock to
relinquish it, so that the main thread could take the lock, and
then call kill-emacs
If we decide to go with the last idea, we need to discuss how to
obtain the lock, it is not trivial, let alone portable.
Paul, when a fatal signal is delivered to Emacs from outside, it goes
to the main thread, but what happens with other threads? do they keep
running as before, or do they stop?
And what about "synchronous" signals like SIGSEGV -- if a non-main
thread triggers such a signal, does the handler run in that thread, or
does it run in the main thread?
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 15:32:01 +0000
Resent-Message-ID: <handler.79318.B79318.175630869022753 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Eli Zaretskii <eliz@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN>
Cc: 79318 <at> debbugs.gnu.org
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.175630869022753
(code B ref 79318); Wed, 27 Aug 2025 15:32:01 +0000
Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 15:31:30 +0000
Received: from localhost ([127.0.0.1]:33630 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1urI7V-0005uu-Ga
for submit <at> debbugs.gnu.org; Wed, 27 Aug 2025 11:31:29 -0400
Received: from mail.cs.ucla.edu ([131.179.128.66]:60792)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eggert@HIDDEN>)
id 1urI7S-0005uB-2g
for 79318 <at> debbugs.gnu.org; Wed, 27 Aug 2025 11:31:26 -0400
Received: from localhost (localhost [127.0.0.1])
by mail.cs.ucla.edu (Postfix) with ESMTP id 356C83C2BEBA7;
Wed, 27 Aug 2025 08:31:20 -0700 (PDT)
Received: from mail.cs.ucla.edu ([127.0.0.1])
by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP
id JPkf2DtKnnD6; Wed, 27 Aug 2025 08:31:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mail.cs.ucla.edu (Postfix) with ESMTP id 0D6D23C328D36;
Wed, 27 Aug 2025 08:31:20 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 0D6D23C328D36
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu;
s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1756308680;
bh=hbmN1QaKVTmsiJ9KW4zgc6OksmypiH8ljXdLpGt+riA=;
h=Message-ID:Date:MIME-Version:To:From;
b=hiyM6SnOBVom94HmFU1rAvCYl2j1XzbZNisQ+JXhjEAlYnt3wqPKZD6ZwcRGb+Q9e
V0Y7/ju4EjLRBIAk+XKckL+hz//CgJONVKx5O0sm6pFr/r6JAVVNHcp/p0WTUVsMzZ
042H7gwRZNhGju/tuiozkuhUS7RKc6cFl28pHBOIYP2/scb4XGvGdsRKngmyDNOyXH
eca89b44chZOWgt9aQUZikpyEOtgHflzq+LA1MDFViUsqPzRkCj803klE85j0/ebK+
0wSaIk2YnhVgPhuvwo3yXqtwjTrcV2ShgqgW1fOvgaZJ0W8doltIqCoLM9yV0bz6xZ
qBj5xr0qc7T6w==
X-Virus-Scanned: amavis at mail.cs.ucla.edu
Received: from mail.cs.ucla.edu ([127.0.0.1])
by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP
id hQyY8kch1l4O; Wed, 27 Aug 2025 08:31:19 -0700 (PDT)
Received: from penguin.cs.ucla.edu
(47-154-18-19.fdr01.snmn.ca.ip.frontiernet.net [47.154.18.19])
by mail.cs.ucla.edu (Postfix) with ESMTPSA id E40A93C2BEBA7;
Wed, 27 Aug 2025 08:31:19 -0700 (PDT)
Message-ID: <73a01708-372c-474e-98b7-ed289538d15d@HIDDEN>
Date: Wed, 27 Aug 2025 08:31:18 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
<ierqzwxlwev.fsf@HIDDEN> <864ittv6si.fsf@HIDDEN>
<CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
<86qzwxt0b4.fsf@HIDDEN>
Content-Language: en-US
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
In-Reply-To: <86qzwxt0b4.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-08-27 05:29, Eli Zaretskii wrote:
> Paul, when a fatal signal is delivered to Emacs from outside, it goes
> to the main thread, but what happens with other threads? do they keep
> running as before, or do they stop?
Those fatal signals go to the main thread because if the OS delivers
them elsewhere, Emacs uses pthread_kill to redeliver them to the main
thread. In this situation the thread that originally got the signal is
suspended. All other threads keep running.
I suppose it's possible that the thread that originally got the signal
is not the main thread, and owns the global lock. If this is the case,
then either the shutdown code should not need to acquire the global
lock, or the thread that originally got the signal should release the
global lock in a safe way. As I recall, when this signal stuff was
written there was no global lock, so perhaps when the global lock was
added the possibility that I describe was not considered.
> And what about "synchronous" signals like SIGSEGV -- if a non-main
> thread triggers such a signal, does the handler run in that thread, or
> does it run in the main thread?
It depends on the signal. A SIGSEGV is considered to be fatal if garbage
collection is in progress, if it is triggered in a non-main thread, or
if Emacs thinks that it was not caused by stack overflow. A non-fatal
SIGSEGV causes Emacs to longjmp back to the top level command loop;
other threads keep running. A fatal SIGSEGV is handled as described above.
The full story is a more complicated on Android and on MS-Windows. It's
not clear from the bug report which platform we're talking about, but I
suspect it's not MS-Windows (where you're the expert and wouldn't need
to ask me) or Android.
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 16:46:01 +0000
Resent-Message-ID: <handler.79318.B79318.175631315110828 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Paul Eggert <eggert@HIDDEN>
Cc: sbaugh@HIDDEN, 79318 <at> debbugs.gnu.org
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.175631315110828
(code B ref 79318); Wed, 27 Aug 2025 16:46:01 +0000
Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 16:45:51 +0000
Received: from localhost ([127.0.0.1]:34143 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1urJHT-0002oa-08
for submit <at> debbugs.gnu.org; Wed, 27 Aug 2025 12:45:51 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:43008)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1urJHP-0002o7-JD
for 79318 <at> debbugs.gnu.org; Wed, 27 Aug 2025 12:45: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 <eliz@HIDDEN>)
id 1urJHF-0005Gb-Rf; Wed, 27 Aug 2025 12:45:38 -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=6aJIWCqeUOrVKhUEDXDWRTCRhaLKQlBtEe9hvlmCylI=; b=QixXx+3ryxQb
3JmhMkNVDv7LkvGCSbS+nzfRTHH1+nzgG0e7+0q0Xfb2tbrRENylDM7qbhP5ZoN1dumxDIx3zeY2u
Z+BaFm7CEoXaH/TcMNBTZP5aCMmjHTSSayewg73IEpu/krvjBJVaAlHg2hTXZ0GdlL+y4x8bagyVy
4zGFUhs5Qm+BrZIXeguxR2kIHKQoT7MrVMhuj+WEmKL6jKWZIJ0FQKbjaXpQ8e1joZaY5TexqSYKd
8m2oxC/Io1T08qgTaoDDhzIk4plOymQBLbAGweq8OHFFfWr+AWbmpjCJEPuDjDRuCt0jIbIWt1XEl
J2ACQoqjT3qvSIQJaOz2eA==;
Date: Wed, 27 Aug 2025 19:44:59 +0300
Message-Id: <86iki8u31w.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <73a01708-372c-474e-98b7-ed289538d15d@HIDDEN> (message from
Paul Eggert on Wed, 27 Aug 2025 08:31:18 -0700)
References: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
<ierqzwxlwev.fsf@HIDDEN> <864ittv6si.fsf@HIDDEN>
<CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
<86qzwxt0b4.fsf@HIDDEN> <73a01708-372c-474e-98b7-ed289538d15d@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Wed, 27 Aug 2025 08:31:18 -0700
> Cc: 79318 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
>
> On 2025-08-27 05:29, Eli Zaretskii wrote:
> > Paul, when a fatal signal is delivered to Emacs from outside, it goes
> > to the main thread, but what happens with other threads? do they keep
> > running as before, or do they stop?
>
> Those fatal signals go to the main thread because if the OS delivers
> them elsewhere, Emacs uses pthread_kill to redeliver them to the main
> thread. In this situation the thread that originally got the signal is
> suspended. All other threads keep running.
>
> I suppose it's possible that the thread that originally got the signal
> is not the main thread, and owns the global lock. If this is the case,
> then either the shutdown code should not need to acquire the global
> lock, or the thread that originally got the signal should release the
> global lock in a safe way. As I recall, when this signal stuff was
> written there was no global lock, so perhaps when the global lock was
> added the possibility that I describe was not considered.
Yes, I think we should do something like that in
deliver_thread_signal.
> > And what about "synchronous" signals like SIGSEGV -- if a non-main
> > thread triggers such a signal, does the handler run in that thread, or
> > does it run in the main thread?
>
> It depends on the signal. A SIGSEGV is considered to be fatal if garbage
> collection is in progress, if it is triggered in a non-main thread, or
> if Emacs thinks that it was not caused by stack overflow. A non-fatal
> SIGSEGV causes Emacs to longjmp back to the top level command loop;
> other threads keep running. A fatal SIGSEGV is handled as described above.
OK, thanks.
> The full story is a more complicated on Android and on MS-Windows. It's
> not clear from the bug report which platform we're talking about, but I
> suspect it's not MS-Windows (where you're the expert and wouldn't need
> to ask me) or Android.
No, it wasn't on Windows, indeed.
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 16:52:03 +0000
Resent-Message-ID: <handler.79318.B79318.175631350812374 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: eggert@HIDDEN
Cc: sbaugh@HIDDEN, 79318 <at> debbugs.gnu.org
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.175631350812374
(code B ref 79318); Wed, 27 Aug 2025 16:52:03 +0000
Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 16:51:48 +0000
Received: from localhost ([127.0.0.1]:34178 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1urJNE-0003DW-8m
for submit <at> debbugs.gnu.org; Wed, 27 Aug 2025 12:51:48 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:39796)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1urJN8-0003Cz-Nf
for 79318 <at> debbugs.gnu.org; Wed, 27 Aug 2025 12:51:44 -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 <eliz@HIDDEN>)
id 1urJMw-0005tr-RQ; Wed, 27 Aug 2025 12:51:30 -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=z3iSwbcJ/KJ66bbNwqJ5IY5mhwwIJs3H9K3ijtILrjo=; b=B0ulqpIKjNBt
whjIoXzO8JwuBiPgGCG5OkSbeF4JHByNCCZ6U1wwXPvW052iJ9WKnQTLqtRVo4ppz4lxbV5qXqC8T
q0zb26CHVuEYoPAYBrc7j4qodXwWAnZUrrzCr+RjRAx4Q4bzCuWV84P6W+vXkfYm7U/NI8x54RmgQ
QW/XKtIiNcab48vIqHwtucrCnSyvIsKM30n0ZFHCgZRbqpzKnr92SN8+kJ8f0fMT0TIJBARtnAv5V
D29zsxHuaJctOlzZj2KfjWaRmgYoXxtWp5q6bNryMrZJ1gwOHFyhcw4R+jHizLJxArckvo+srH6RY
iy/qRxNz4wH/CEwadvidVg==;
Date: Wed, 27 Aug 2025 19:51:16 +0300
Message-Id: <86h5xsu2rf.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <86iki8u31w.fsf@HIDDEN> (message from Eli Zaretskii on Wed, 27
Aug 2025 19:44:59 +0300)
References: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
<ierqzwxlwev.fsf@HIDDEN> <864ittv6si.fsf@HIDDEN>
<CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
<86qzwxt0b4.fsf@HIDDEN> <73a01708-372c-474e-98b7-ed289538d15d@HIDDEN>
<86iki8u31w.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Cc: sbaugh@HIDDEN, 79318 <at> debbugs.gnu.org
> Date: Wed, 27 Aug 2025 19:44:59 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
>
> > Date: Wed, 27 Aug 2025 08:31:18 -0700
> > Cc: 79318 <at> debbugs.gnu.org
> > From: Paul Eggert <eggert@HIDDEN>
> >
> > On 2025-08-27 05:29, Eli Zaretskii wrote:
> > > Paul, when a fatal signal is delivered to Emacs from outside, it goes
> > > to the main thread, but what happens with other threads? do they keep
> > > running as before, or do they stop?
> >
> > Those fatal signals go to the main thread because if the OS delivers
> > them elsewhere, Emacs uses pthread_kill to redeliver them to the main
> > thread. In this situation the thread that originally got the signal is
> > suspended. All other threads keep running.
> >
> > I suppose it's possible that the thread that originally got the signal
> > is not the main thread, and owns the global lock. If this is the case,
> > then either the shutdown code should not need to acquire the global
> > lock, or the thread that originally got the signal should release the
> > global lock in a safe way. As I recall, when this signal stuff was
> > written there was no global lock, so perhaps when the global lock was
> > added the possibility that I describe was not considered.
>
> Yes, I think we should do something like that in
> deliver_thread_signal.
Actually, one more question about that: didn't you tell me at some
point that on GNU/Linux the OS takes care of delivering fatal signals
to the main thread? If that is so, then we have no control on what
happens with the global lock in this case, because
deliver_thread_signal is bypassed, and we might find ourselves in the
situation whereby a non-main thread was running some Lisp, then
triggered a fatal signal or some external source delivered a fatal
signal, and the OS runs the signal handler on the main thread which
doesn't own the global lock. Is this possible?
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 18:12:03 +0000
Resent-Message-ID: <handler.79318.B79318.17563183163042 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Eli Zaretskii <eliz@HIDDEN>
Cc: sbaugh@HIDDEN, 79318 <at> debbugs.gnu.org
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.17563183163042
(code B ref 79318); Wed, 27 Aug 2025 18:12:03 +0000
Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 18:11:56 +0000
Received: from localhost ([127.0.0.1]:34767 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1urKcl-0000mu-14
for submit <at> debbugs.gnu.org; Wed, 27 Aug 2025 14:11:55 -0400
Received: from mail.cs.ucla.edu ([131.179.128.66]:34936)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eggert@HIDDEN>)
id 1urKcY-0000lq-9Y
for 79318 <at> debbugs.gnu.org; Wed, 27 Aug 2025 14:11:43 -0400
Received: from localhost (localhost [127.0.0.1])
by mail.cs.ucla.edu (Postfix) with ESMTP id DEB6C3C10C5FB;
Wed, 27 Aug 2025 11:11:34 -0700 (PDT)
Received: from mail.cs.ucla.edu ([127.0.0.1])
by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP
id 5dOpu4ziQSRZ; Wed, 27 Aug 2025 11:11:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mail.cs.ucla.edu (Postfix) with ESMTP id B606D3C32B0EA;
Wed, 27 Aug 2025 11:11:34 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu B606D3C32B0EA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu;
s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1756318294;
bh=CZdA8MAnR2cE9qVIVq5cape5XqsPe8td7xgHbfRIZOU=;
h=Message-ID:Date:MIME-Version:To:From;
b=jysfSZeKhBuPDqJd2eVeTeK7BnRM/G+3BUzqoOjq4r6pr/8+RgRY8/vdk0wfHCiQR
fdJW87kY0N9Gx1dPozcu6EEa+pYC4b0sZkvLAakA1PHEVTdiEg0mV6vLI0xbyw9J3C
85OqyAhxysZ/rIKyLDNYuH21YdNUDCMlLou4hRroPsAfPUlnNiVd7FhugtJpJ4oger
BTzDCL7KHejRR/bsbdW72l7z2re8IBfLlJg0oQPDd9CHQTX5jqUQ4emp0hYNc2QTB7
+8752T5lW75miq960E96wLnJZkiA3S4eMmshHTq8LhwiVaF9rT9BNSSkzVOZ8d2Apw
gQbgQy0wjtA7Q==
X-Virus-Scanned: amavis at mail.cs.ucla.edu
Received: from mail.cs.ucla.edu ([127.0.0.1])
by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP
id aeUhBZqsjQm2; Wed, 27 Aug 2025 11:11:34 -0700 (PDT)
Received: from penguin.cs.ucla.edu
(47-154-18-19.fdr01.snmn.ca.ip.frontiernet.net [47.154.18.19])
by mail.cs.ucla.edu (Postfix) with ESMTPSA id 8C20A3C10C5FB;
Wed, 27 Aug 2025 11:11:34 -0700 (PDT)
Message-ID: <4c8702cc-5094-4f27-8f9b-afc667ea484e@HIDDEN>
Date: Wed, 27 Aug 2025 11:11:34 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
<ierqzwxlwev.fsf@HIDDEN> <864ittv6si.fsf@HIDDEN>
<CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
<86qzwxt0b4.fsf@HIDDEN> <73a01708-372c-474e-98b7-ed289538d15d@HIDDEN>
<86iki8u31w.fsf@HIDDEN> <86h5xsu2rf.fsf@HIDDEN>
Content-Language: en-US
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
In-Reply-To: <86h5xsu2rf.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2025-08-27 09:51, Eli Zaretskii wrote:
> didn't you tell me at some
> point that on GNU/Linux the OS takes care of delivering fatal signals
> to the main thread?
What I recall saying long ago is pretty much what I wrote earlier today,
namely that if a fatal signal is delivered to a non-main thread, Emacs
code in the non-main thread arranges to redeliver the signal to the main
thread.
If that is so, then we have no control on what
> happens with the global lock in this case, because
> deliver_thread_signal is bypassed, and we might find ourselves in the
> situation whereby a non-main thread was running some Lisp, then
> triggered a fatal signal or some external source delivered a fatal
> signal, and the OS runs the signal handler on the main thread which
> doesn't own the global lock. Is this possible?
Sounds like it, yes. It could also happen if the kernel decides to
deliver the externally-sourced signal to the main thread in the first
place. POSIX allows this.
X-Loop: help-debbugs@HIDDEN
Subject: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 18:20:02 +0000
Resent-Message-ID: <handler.79318.B79318.17563187755189 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79318
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Paul Eggert <eggert@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 79318 <at> debbugs.gnu.org
Received: via spool by 79318-submit <at> debbugs.gnu.org id=B79318.17563187755189
(code B ref 79318); Wed, 27 Aug 2025 18:20:02 +0000
Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 18:19:35 +0000
Received: from localhost ([127.0.0.1]:34824 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1urKkA-0001Lc-9Z
for submit <at> debbugs.gnu.org; Wed, 27 Aug 2025 14:19:34 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:47049)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1urKk2-0001K8-0G
for 79318 <at> debbugs.gnu.org; Wed, 27 Aug 2025 14:19:27 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <4c8702cc-5094-4f27-8f9b-afc667ea484e@HIDDEN> (Paul Eggert's
message of "Wed, 27 Aug 2025 11:11:34 -0700")
References: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
<ierqzwxlwev.fsf@HIDDEN> <864ittv6si.fsf@HIDDEN>
<CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
<86qzwxt0b4.fsf@HIDDEN>
<73a01708-372c-474e-98b7-ed289538d15d@HIDDEN>
<86iki8u31w.fsf@HIDDEN> <86h5xsu2rf.fsf@HIDDEN>
<4c8702cc-5094-4f27-8f9b-afc667ea484e@HIDDEN>
Date: Wed, 27 Aug 2025 14:19:19 -0400
Message-ID: <ierms7k8w60.fsf@HIDDEN>
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=1756318759;
bh=Mrp48nWz2fStSN3VmJMSHRb5DEhYVRawUAT32b8LaC8=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=vVdjzak19EKB0tvS+O7m3PaZUOBwSPIowcM6dA6e0qMbA0i0WE9c12Rdm2zIS+v8n
p7xuZDgMM1jPDYdjPliVZi8Zo6MbiO4Es0K/u3+I+7tNL8cBS2JEvtZOQcg1Ui4s1f
REF8384hG5FOBbiGRs+yIdwvCOvbp1bor6aYbaajWLZW95bQ07PN0C8aEOmDwYME2B
Ugq6uH78ZUYkPSp85IcQ+yBdA1US26xVOhy9lfECKRgrRaZt0pY9TFwur4/Sa7yRt+
jAYr6wg0/G2opCDp+tGN2Sf0LClLy0+GAbSXbWKvTuhvoViZgOyuCMNxfujY+TwlFt
GZfcvX01mNjXw==
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Paul Eggert <eggert@HIDDEN> writes:
> On 2025-08-27 09:51, Eli Zaretskii wrote:
>> If that is so, then we have no control on what
>> happens with the global lock in this case, because
>> deliver_thread_signal is bypassed, and we might find ourselves in the
>> situation whereby a non-main thread was running some Lisp, then
>> triggered a fatal signal or some external source delivered a fatal
>> signal, and the OS runs the signal handler on the main thread which
>> doesn't own the global lock. Is this possible?
>
> Sounds like it, yes. It could also happen if the kernel decides to
> deliver the externally-sourced signal to the main thread in the first
> place. POSIX allows this.
Perhaps we could change to deliver signals to whatever thread currently
holds the lock, instead of to the main thread.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.