Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 18:19:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 27 14:19:34 2025 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> To: Paul Eggert <eggert@HIDDEN> Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault 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-Debbugs-Envelope-To: 79318 Cc: Eli Zaretskii <eliz@HIDDEN>, 79318 <at> debbugs.gnu.org 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.
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 18:11:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 27 14:11:55 2025 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 Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault To: Eli Zaretskii <eliz@HIDDEN> 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-Debbugs-Envelope-To: 79318 Cc: sbaugh@HIDDEN, 79318 <at> debbugs.gnu.org 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.
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 16:51:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 27 12:51:48 2025 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> To: eggert@HIDDEN In-Reply-To: <86iki8u31w.fsf@HIDDEN> (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: <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-Debbugs-Envelope-To: 79318 Cc: sbaugh@HIDDEN, 79318 <at> debbugs.gnu.org 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?
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 16:45:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 27 12:45:51 2025 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> To: Paul Eggert <eggert@HIDDEN> In-Reply-To: <73a01708-372c-474e-98b7-ed289538d15d@HIDDEN> (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: <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-Debbugs-Envelope-To: 79318 Cc: sbaugh@HIDDEN, 79318 <at> debbugs.gnu.org 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.
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 15:31:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 27 11:31:29 2025 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 Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault To: Eli Zaretskii <eliz@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN> 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-Debbugs-Envelope-To: 79318 Cc: 79318 <at> debbugs.gnu.org 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.
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.
Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 12:29:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 27 08:29:58 2025
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>
To: eggert@HIDDEN, Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
(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: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN>
<ierqzwxlwev.fsf@HIDDEN> <864ittv6si.fsf@HIDDEN>
<CAO=BR8MJv-XkEos_8T0TkOUURHg-ZUG35QpYeCxzTp9iHziChQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79318
Cc: 79318 <at> debbugs.gnu.org
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?
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 05:07:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 27 01:07:42 2025 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> Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000e08934063d51c3ec" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: 79318 <at> debbugs.gnu.org, eggert@HIDDEN 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--
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.Received: (at 79318) by debbugs.gnu.org; 27 Aug 2025 02:26:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 26 22:26:53 2025 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> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ierqzwxlwev.fsf@HIDDEN> (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: <iertt1ukqdg.fsf@HIDDEN> <867bypvs5s.fsf@HIDDEN> <ierqzwxlwev.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: 79318 <at> debbugs.gnu.org, eggert@HIDDEN 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.
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.Received: (at 79318) by debbugs.gnu.org; 26 Aug 2025 19:23:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 26 15:23:31 2025 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> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault 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-Debbugs-Envelope-To: 79318 Cc: 79318 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.Received: (at 79318) by debbugs.gnu.org; 26 Aug 2025 18:45:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 26 14:45:29 2025 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> To: Spencer Baugh <sbaugh@HIDDEN>, Paul Eggert <eggert@HIDDEN> In-Reply-To: <iertt1ukqdg.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#79318: 31.1.90; Threads + receiving a signal causes a segfault References: <iertt1ukqdg.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79318 Cc: 79318 <at> debbugs.gnu.org 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?
bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 26 Aug 2025 16:20:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 26 12:20:31 2025
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>
To: bug-gnu-emacs@HIDDEN
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: <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-Debbugs-Envelope-To: submit
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
Spencer Baugh <sbaugh@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#79318; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.