From unknown Sun Sep 07 16:50:49 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#79318 <79318@debbugs.gnu.org> To: bug#79318 <79318@debbugs.gnu.org> Subject: Status: 31.1.90; Threads + receiving a signal causes a segfault Reply-To: bug#79318 <79318@debbugs.gnu.org> Date: Sun, 07 Sep 2025 23:50:49 +0000 retitle 79318 31.1.90; Threads + receiving a signal causes a segfault reassign 79318 emacs submitter 79318 Spencer Baugh severity 79318 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 26 12:20:31 2025 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 ) id 1uqwPN-0000bQ-Op for submit@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 ) id 1uqwPH-0000W2-SL for submit@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 ) id 1uqwOn-0001Wy-C7 for bug-gnu-emacs@gnu.org; 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 ) id 1uqwO8-0000ce-Gl for bug-gnu-emacs@gnu.org; Tue, 26 Aug 2025 12:19:20 -0400 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: 31.1.90; Threads + receiving a signal causes a segfault X-Debbugs-Cc: Date: Tue, 26 Aug 2025 12:19:07 -0400 Message-ID: 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@janestreet.com; 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-Debbugs-Envelope-To: submit 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.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 = #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 ) at sysdep.c:1758 old_errno = 4 on_main_thread = true #4 0x00007fffefc12970 in () 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 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 ) at lisp.h:4509 sa = { func = 0x419450 , max_fds = 6, rfds = 0x7fffffffbc70, wfds = 0x7fffffffbcf0, efds = 0x0, timeout = 0x7fffffffc280, sigmask = 0x0, result = -135497884 } #8 0x000000000063bd7e in thread_select (func=, 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 , 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 } } all_wfds = { fds_bits = {0 } } tmo = { tv_sec = 0, tv_nsec = 0 } tmop = 0x7fffffffc280 context = 0xdb81a0 have_wfds = 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 = n_gfds = retval = 0 our_fds = 0 max_fds = i = nfds = tmo_in_millisec = -1 must_free = need_to_dispatch = #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 } } process_skipped = wrapped = channel_start = child_fd = last_read_channel = -1 channel = nfds = Available = { fds_bits = {0 } } Writeok = { fds_bits = {0 } } check_write = true check_delay = no_avail = false xerrno = 4 proc = timeout = { tv_sec = 99, tv_nsec = 999925830 } end_time = timer_delay = 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 = now = #11 0x000000000042788b in Fsleep_for (seconds=, milliseconds=) at lisp.h:1192 t = { tv_sec = 100, tv_nsec = 0 } tend = { tv_sec = 1756225164, tv_nsec = 695603177 } duration = #12 0x00000000005c1f2e in eval_sub (form=) at lisp.h:2243 i = maxargs = 2 args_left = XIL(0) numargs = 1 original_fun = original_args = XIL(0x7ffff73ae593) count = { bytes = 1024 } fun = val = funcar = 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=, macroexpand=XIL(0xb340)) at lisp.h:1192 #14 0x00000000005f0dbf in readevalloop (readcharfun=XIL(0xe57515), infile0=0x0, sourcename=XIL(0xe213f4), printflag=false, unibyte=, readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2548 c = val = XIL(0x7ffff73ae583) b = continue_reading_p = true lex_bound = whole_buffer = true first_sexp = macroexpand = XIL(0xb340) #15 0x00000000005f2070 in Feval_buffer (buffer=, printflag=XIL(0), filename=XIL(0xe213f4), unibyte=XIL(0), do_allow_print=) 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 = #18 0x00000000005f1879 in Fload (file=XIL(0xe210a4), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=, must_suffix=) at lisp.h:1488 val = stream = 0x0 fd = 5 found = XIL(0xe213f4) efound = hist_file_name = newer = false compiled = false handler = fmode = 0x6b41e7 "r" version = 0 no_native = false is_module = false is_native_elisp = false found_eff = 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 = #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 = #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=) at lisp.h:2243 i = 0 maxargs = args_left = XIL(0) numargs = 0 original_fun = original_args = XIL(0) count = { bytes = 128 } fun = val = funcar = 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 = #27 0x00000000005bd532 in internal_condition_case (bfun=bfun@entry=0x537e90 , handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x53f140 ) at eval.c:1617 val = 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 , arg=arg@entry=XIL(0)) at eval.c:1296 val = c = 0xef0e00 #30 0x0000000000537dbb in command_loop () at lisp.h:1192 #31 0x000000000053ecf6 in recursive_edit_1 () at keyboard.c:754 val = #32 0x000000000053f084 in Frecursive_edit () at keyboard.c:837 buffer = #33 0x00000000004267a7 in main (argc=, argv=) at emacs.c:2646 stack_bottom_variable = 0xc4acf64ff28ad800 old_argc = no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = dump_mode = skip_args = 1 temacs = 0x0 attempt_load_pdump = only_version = rlim = { rlim_cur = 10022912, rlim_max = 18446744073709551615 } lc_all = sockfd = -1 module_assertions = 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 26 14:45:29 2025 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 ) id 1uqyfh-0007vU-Am for submit@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 ) id 1uqyfd-0007vF-5c for 79318@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 ) 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@gnu.org> From: Eli Zaretskii To: Spencer Baugh , Paul Eggert In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: 79318@debbugs.gnu.org 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, 26 Aug 2025 12:19:07 -0400 > From: Spencer Baugh via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > 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? From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 26 15:23:31 2025 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 ) id 1uqzGU-0001G1-Mf for submit@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 ) id 1uqzGR-0001Fh-CE for 79318@debbugs.gnu.org; Tue, 26 Aug 2025 15:23:27 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault In-Reply-To: <867bypvs5s.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 26 Aug 2025 21:45:03 +0300") References: <867bypvs5s.fsf@gnu.org> Date: Tue, 26 Aug 2025 15:23:20 -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=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-Debbugs-Envelope-To: 79318 Cc: 79318@debbugs.gnu.org, Paul Eggert 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, 26 Aug 2025 12:19:07 -0400 >> From: Spencer Baugh via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> >> 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 26 22:26:53 2025 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 ) id 1ur5sC-0006Bw-TF for submit@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 ) id 1ur5s9-0006Bg-8E for 79318@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 ) 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@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Tue, 26 Aug 2025 15:23:20 -0400) Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault References: <867bypvs5s.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: 79318@debbugs.gnu.org, eggert@cs.ucla.edu 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: Paul Eggert , 79318@debbugs.gnu.org > Date: Tue, 26 Aug 2025 15:23:20 -0400 > > Eli Zaretskii 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" > >> > >> > >> 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 01:07:42 2025 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 ) id 1ur8Np-0008TM-KW for submit@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 ) id 1ur8Nk-0008Sp-JH for 79318@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@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@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: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> In-Reply-To: <864ittv6si.fsf@gnu.org> From: Spencer Baugh Date: Wed, 27 Aug 2025 01:07:17 -0400 X-Gm-Features: Ac12FXwnYNOClu7l3GusuEUwB8Zy7sUNxj4o_14-bYHWsQp3w-HnM5qyoduOhIg Message-ID: Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000e08934063d51c3ec" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: 79318@debbugs.gnu.org, eggert@cs.ucla.edu 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 (---) --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 wrote: > > From: Spencer Baugh > > Cc: Paul Eggert , 79318@debbugs.gnu.org > > Date: Tue, 26 Aug 2025 15:23:20 -0400 > > > > Eli Zaretskii 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" > > >> > > >> > > >> 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


On Tue, Aug 26, 2025, 10:26=E2= =80=AFPM Eli Zaretskii <eliz@gnu.org= > wrote:
> From: Spencer Baug= h <sbaugh@janestreet.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,=C2=A0 79318@debbugs= .gnu.org
> Date: Tue, 26 Aug 2025 15:23:20 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Date: Tue, 26 Aug 2025 12:19:07 -0400
> >> From:=C2=A0 Spencer Baugh via "Bug reports for GNU Emacs= ,
> >>=C2=A0 the Swiss army knife of text editors" <bug-= gnu-emacs@gnu.org>
> >>
> >>
> >> repro.el:
> >>
> >> (make-thread
> >>=C2=A0 (lambda ()
> >>=C2=A0 =C2=A0 (sleep-for .1)
> >>=C2=A0 =C2=A0 (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 -- P= aul,
> > am I right?)
>
> The backtrace is of the point at which there's a segfault.=C2=A0 I= t 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 do= es not.
--000000000000e08934063d51c3ec-- From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 08:29:58 2025 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 ) id 1urFHq-0002So-7M for submit@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 ) id 1urFHk-0002SL-Fb for 79318@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 ) 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@gnu.org> From: Eli Zaretskii To: eggert@cs.ucla.edu, Spencer Baugh In-Reply-To: (message from Spencer Baugh on Wed, 27 Aug 2025 01:07:17 -0400) Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault References: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: 79318@debbugs.gnu.org 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 > Date: Wed, 27 Aug 2025 01:07:17 -0400 > Cc: eggert@cs.ucla.edu, 79318@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? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 11:31:29 2025 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 ) id 1urI7V-0005uu-Ga for submit@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 ) id 1urI7S-0005uB-2g for 79318@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@cs.ucla.edu> Date: Wed, 27 Aug 2025 08:31:18 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault To: Eli Zaretskii , Spencer Baugh References: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> <86qzwxt0b4.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86qzwxt0b4.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79318 Cc: 79318@debbugs.gnu.org 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 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 12:45:51 2025 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 ) id 1urJHT-0002oa-08 for submit@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 ) id 1urJHP-0002o7-JD for 79318@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 ) 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@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <73a01708-372c-474e-98b7-ed289538d15d@cs.ucla.edu> (message from Paul Eggert on Wed, 27 Aug 2025 08:31:18 -0700) Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault References: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> <86qzwxt0b4.fsf@gnu.org> <73a01708-372c-474e-98b7-ed289538d15d@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: sbaugh@janestreet.com, 79318@debbugs.gnu.org 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, 27 Aug 2025 08:31:18 -0700 > Cc: 79318@debbugs.gnu.org > From: Paul Eggert > > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 12:51:48 2025 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 ) id 1urJNE-0003DW-8m for submit@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 ) id 1urJN8-0003Cz-Nf for 79318@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 ) 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@gnu.org> From: Eli Zaretskii To: eggert@cs.ucla.edu In-Reply-To: <86iki8u31w.fsf@gnu.org> (message from Eli Zaretskii on Wed, 27 Aug 2025 19:44:59 +0300) Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault References: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> <86qzwxt0b4.fsf@gnu.org> <73a01708-372c-474e-98b7-ed289538d15d@cs.ucla.edu> <86iki8u31w.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: sbaugh@janestreet.com, 79318@debbugs.gnu.org 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: sbaugh@janestreet.com, 79318@debbugs.gnu.org > Date: Wed, 27 Aug 2025 19:44:59 +0300 > From: Eli Zaretskii > > > Date: Wed, 27 Aug 2025 08:31:18 -0700 > > Cc: 79318@debbugs.gnu.org > > From: Paul Eggert > > > > 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? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 14:11:55 2025 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 ) id 1urKcl-0000mu-14 for submit@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 ) id 1urKcY-0000lq-9Y for 79318@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@cs.ucla.edu> Date: Wed, 27 Aug 2025 11:11:34 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault To: Eli Zaretskii References: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> <86qzwxt0b4.fsf@gnu.org> <73a01708-372c-474e-98b7-ed289538d15d@cs.ucla.edu> <86iki8u31w.fsf@gnu.org> <86h5xsu2rf.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86h5xsu2rf.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79318 Cc: sbaugh@janestreet.com, 79318@debbugs.gnu.org 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 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 14:19:34 2025 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 ) id 1urKkA-0001Lc-9Z for submit@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 ) id 1urKk2-0001K8-0G for 79318@debbugs.gnu.org; Wed, 27 Aug 2025 14:19:27 -0400 From: Spencer Baugh To: Paul Eggert Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault In-Reply-To: <4c8702cc-5094-4f27-8f9b-afc667ea484e@cs.ucla.edu> (Paul Eggert's message of "Wed, 27 Aug 2025 11:11:34 -0700") References: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> <86qzwxt0b4.fsf@gnu.org> <73a01708-372c-474e-98b7-ed289538d15d@cs.ucla.edu> <86iki8u31w.fsf@gnu.org> <86h5xsu2rf.fsf@gnu.org> <4c8702cc-5094-4f27-8f9b-afc667ea484e@cs.ucla.edu> Date: Wed, 27 Aug 2025 14:19: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=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-Debbugs-Envelope-To: 79318 Cc: Eli Zaretskii , 79318@debbugs.gnu.org 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 (---) Paul Eggert 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 14:34:41 2025 Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 18:34:41 +0000 Received: from localhost ([127.0.0.1]:34929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1urKym-0005Fk-N1 for submit@debbugs.gnu.org; Wed, 27 Aug 2025 14:34:41 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:41704) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1urKyh-0005Ez-KP for 79318@debbugs.gnu.org; Wed, 27 Aug 2025 14:34:36 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 7D4603C306627; Wed, 27 Aug 2025 11:34:29 -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 58sXBzXvXP6U; Wed, 27 Aug 2025 11:34:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 550713C32B0EA; Wed, 27 Aug 2025 11:34:29 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 550713C32B0EA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1756319669; bh=9G5MQdj27HFFHOXiscCG+17jNJktPp3McidlBPd5r+c=; h=Message-ID:Date:MIME-Version:To:From; b=MGeJameLZ8AoKWfOWmRW35V+8N2tocO1ok7QWRV00GSI+PNLbjRwr8nFWWyLBGOvr ktVfg8onz3WEKsj3zJGyQNcA7Wa2T6e84EUip6Uz7Idp6VWbTRXbcZXLuSZDh2EEA2 I5xKsGcQ1caXsYRKH6AbSU0Oo487RqSx7L7bCA7j8YsiUmKl46tj8JyBX0IDIcXL6y A2wyWrjuq/NauKDwtlo82yR+UCRHIiNyeqnMfrXsWbeFjlZUe/GVBrW1C5kNbSYX/I 51cX4HOTiQ83DtNeM+Zwk7etV+vJt17ChwKcFZr45xcRPCn8+or0qBH/S17mogfCii vqR0qYjhVyF4w== 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 tI7WJxI1OTJH; Wed, 27 Aug 2025 11:34:29 -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 319763C306627; Wed, 27 Aug 2025 11:34:29 -0700 (PDT) Message-ID: <171b6a1d-9046-4c2e-be54-a38e0ec1308c@cs.ucla.edu> Date: Wed, 27 Aug 2025 11:34:27 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault To: Spencer Baugh References: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> <86qzwxt0b4.fsf@gnu.org> <73a01708-372c-474e-98b7-ed289538d15d@cs.ucla.edu> <86iki8u31w.fsf@gnu.org> <86h5xsu2rf.fsf@gnu.org> <4c8702cc-5094-4f27-8f9b-afc667ea484e@cs.ucla.edu> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79318 Cc: Eli Zaretskii , 79318@debbugs.gnu.org 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 (-) On 2025-08-27 11:19, Spencer Baugh wrote: > Perhaps we could change to deliver signals to whatever thread currently > holds the lock, instead of to the main thread. Something like that might work, but it's tricky. First, how do you determine (in a thread-safe way) whether some other thread holds the lock and if so, which thread, and if so, how to signal that thread before it gives up its lock or exits? Second, even if you hold the lock, how do you finish out your critical section without corrupting the state and without introducing other possibilities for hanging? I'm glad someone *else* will write all that code.... From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 15:22:36 2025 Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 19:22:36 +0000 Received: from localhost ([127.0.0.1]:35364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1urLj6-0000hX-T4 for submit@debbugs.gnu.org; Wed, 27 Aug 2025 15:22:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55334) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1urLit-0000gR-Vr for 79318@debbugs.gnu.org; Wed, 27 Aug 2025 15:22:27 -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 1urLin-0007A3-1w; Wed, 27 Aug 2025 15:22: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=Tp9r5eAhKtr1PUQlGjvaEiz9kWKMkePepYgIA/kHZDc=; b=T7kH7o65EDvs +6SUbGmwx3lubyq5HLMOxBB5GFGlgTUxOfG3urD/jNYEQUI6dWbjkODk+16ADggtJKAe9IuOJLcpZ 6Pnx38UfUhXrskkoysE/Wvb1SDvGeZ3Z5By7r5jq9AgP+dunkE7sohJ583pgYe9iBU0uzMAt7ek/D R7YfgrS3nyQqxXPcy961gacIxHv1VsWGVTaxIYqstI7FX3myvM0Kw1vPX6TaUqeuO6BMkPB40WS+A iDAnLY+dtpcYIt1VXQ6gBifQPc+uzCPOjXPGjeIVqz0+wYxL9P/nZhubfy3swuleb6FjGR5UwOqN5 CD5qGER0PvaxxdgYgjm8Zw==; Date: Wed, 27 Aug 2025 22:22:09 +0300 Message-Id: <86bjo0tvry.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <4c8702cc-5094-4f27-8f9b-afc667ea484e@cs.ucla.edu> (message from Paul Eggert on Wed, 27 Aug 2025 11:11:34 -0700) Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault References: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> <86qzwxt0b4.fsf@gnu.org> <73a01708-372c-474e-98b7-ed289538d15d@cs.ucla.edu> <86iki8u31w.fsf@gnu.org> <86h5xsu2rf.fsf@gnu.org> <4c8702cc-5094-4f27-8f9b-afc667ea484e@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: sbaugh@janestreet.com, 79318@debbugs.gnu.org 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, 27 Aug 2025 11:11:34 -0700 > Cc: sbaugh@janestreet.com, 79318@debbugs.gnu.org > From: Paul Eggert > > 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. OK, thanks. So we still need to have some device in place for if and when that happens, if we want to be able to run Lisp from the signal handler. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 15:23:31 2025 Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 19:23:31 +0000 Received: from localhost ([127.0.0.1]:35386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1urLk2-0000m8-VF for submit@debbugs.gnu.org; Wed, 27 Aug 2025 15:23:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41828) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1urLjx-0000lF-S7 for 79318@debbugs.gnu.org; Wed, 27 Aug 2025 15:23:27 -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 1urLjo-0007U0-Kw; Wed, 27 Aug 2025 15:23: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=3HEYhjKi21YM6WcFjc8xJjOgDio3dHjV1S04tr1xAqA=; b=Q6FYocVyjPXs ya6+x4HCMULwjeW/y9CtoB00e1DBmSl3Dg7elbrtcHkmMnlxWPe7kV/uIN3I7Y1Xqa4f44h59QJ7E 2TcxXBBbzbuNfp/iHl3lfMttm81vDotXTUVObhptxv96Ik6BdqbMssQ2YihiUgyXpfN7s68mop3DO z2ZqltBQSbcCiqpfs27Zj2u/QBLhbj8SBkTKKRv05H4FjP0o1jDtd1r5NrzrjBkKLipbwoYoxTlHr zGkNzWn+nKYk4v1xBX6oWOdFALdUa8FRCCEC50Vse1/a1boiheX5oIhz6Hrl6f4sGJnTMqCykHbvU XZEmwS3vliE/+01bb+P26g==; Date: Wed, 27 Aug 2025 22:23:14 +0300 Message-Id: <86a53ktvq5.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Wed, 27 Aug 2025 14:19:19 -0400) Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault References: <867bypvs5s.fsf@gnu.org> <864ittv6si.fsf@gnu.org> <86qzwxt0b4.fsf@gnu.org> <73a01708-372c-474e-98b7-ed289538d15d@cs.ucla.edu> <86iki8u31w.fsf@gnu.org> <86h5xsu2rf.fsf@gnu.org> <4c8702cc-5094-4f27-8f9b-afc667ea484e@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: 79318@debbugs.gnu.org, eggert@cs.ucla.edu 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: Eli Zaretskii , 79318@debbugs.gnu.org > Date: Wed, 27 Aug 2025 14:19:19 -0400 > > Paul Eggert 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. If that works reliably, yes, that's a possibility.