From unknown Sun Aug 10 11:49:30 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#70144 <70144@debbugs.gnu.org> To: bug#70144 <70144@debbugs.gnu.org> Subject: Status: system* affects signal handlers Reply-To: bug#70144 <70144@debbugs.gnu.org> Date: Sun, 10 Aug 2025 18:49:30 +0000 retitle 70144 system* affects signal handlers reassign 70144 guile submitter 70144 Christopher Baines severity 70144 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 02 10:27:53 2024 Received: (at submit) by debbugs.gnu.org; 2 Apr 2024 14:27:53 +0000 Received: from localhost ([127.0.0.1]:54914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrf7A-00007u-1x for submit@debbugs.gnu.org; Tue, 02 Apr 2024 10:27:52 -0400 Received: from lists.gnu.org ([2001:470:142::17]:37318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrf78-00007D-8d for submit@debbugs.gnu.org; Tue, 02 Apr 2024 10:27:50 -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 1rrf6z-0007WA-0w for bug-guile@gnu.org; Tue, 02 Apr 2024 10:27:41 -0400 Received: from mira.cbaines.net ([212.71.252.8]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rrf6w-0001Em-SF for bug-guile@gnu.org; Tue, 02 Apr 2024 10:27:40 -0400 Received: from localhost (unknown [212.132.255.10]) by mira.cbaines.net (Postfix) with ESMTPSA id 7FE4727BBE2 for ; Tue, 2 Apr 2024 15:27:36 +0100 (BST) Received: from felis (localhost.lan [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 64aafc7b for ; Tue, 2 Apr 2024 14:27:35 +0000 (UTC) User-agent: mu4e 1.10.8; emacs 29.1 From: Christopher Baines To: bug-guile@gnu.org Subject: system* affects signal handlers Date: Tue, 02 Apr 2024 15:22:57 +0100 Message-ID: <87msqbrga2.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=212.71.252.8; envelope-from=mail@cbaines.net; helo=mira.cbaines.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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 (/) --=-=-= Content-Type: text/plain I've encountered a situation where signal handlers don't seem to run. With the following program, sending it SIGINT won't trigger the handler, however if you remove the system* call, then the handler will run. (use-modules (ice-9 threads)) (call-with-new-thread (lambda () ;; Remove the following system* call to fix the handler (system* "echo" "foo"))) (sigaction SIGINT (lambda (sig) (peek "SIGINT handler") (exit 1))) (for-each (lambda _ (sleep 1)) (iota 30)) (display "normal exit\n") --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmYMFdVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XeT8A//T9WPoR3Lf6KFgURg1hEC9RLYQWMq1nnK iRBpMIjhLO/bmsyess9xmmfpWSwFd2uZ9fPYRAYuoiyQJ3m7IxLZUupNXrkxKngu 7Fo/eynZneBTONrdk+Zq24jwhC/SXf23y0M6EA+IPaYWksLSTRtx3D2ozuibERLm IcIEPQpQ/QKWbP7XQgoNBJQKZS0XiRDSe+yYR3laJQhiRham6Oj4JN8AQO/wh/q5 D968uDQMdlU4LyIk894HESklgKkr3GeEX0ctAGnVdCB5CZ5OkBd2yF6laDdV/hiV SxDnr/3cnBngJxORW4KA4V3v+ufduoLNNrS/Un1tkdixfciJ8m8WEHa7suwvqf/z 7fsmnmwb9SSd0PJhMxU4XogTaJyudZMrdKAUeuRosBp+Io/81vCyYElvE2xylZd5 AIeS4mKmj8ksz8/98MzeUey0coImNwyIsCHV+6rYzaZnpEwmM9k7iGaszg6gUT1V vZOlz4qUYYMZ90MDvS5yQAUU6riaGuHastLzx9iN3sCxpTohDJW1yG8vfrbbAcJf aLNXE5gOQfr7rg24DLAY7xBLbC0aQXR+w2q3SuUkKAmKEvZYlGaD7C2Rt9YznBEE BScTY/UWxGZa43VGrgTj0Y1C04CO+JWuf/g8aRbUI34yhl3mGJY1GDQM2w7ID88Z 7o64f1cP8MY= =ZOq1 -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 03 04:28:35 2024 Received: (at 70144) by debbugs.gnu.org; 3 Apr 2024 08:28:35 +0000 Received: from localhost ([127.0.0.1]:56991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrvz0-0006Zq-4y for submit@debbugs.gnu.org; Wed, 03 Apr 2024 04:28:34 -0400 Received: from mail-ua1-f52.google.com ([209.85.222.52]:53564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrvyx-0006Z3-4n for 70144@debbugs.gnu.org; Wed, 03 Apr 2024 04:28:32 -0400 Received: by mail-ua1-f52.google.com with SMTP id a1e0cc1a2514c-7e3b3e33aa7so311971241.3 for <70144@debbugs.gnu.org>; Wed, 03 Apr 2024 01:28:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712132901; x=1712737701; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/NHKnkUwWH8cRWvne61axlH6wxCuwQYGH6E9bDG/yno=; b=QYSChWD4lEf78B4QIATh42p6g6VGsEl4SNYAsSOJtDtWQwhLSd5As3X38BzTqLgXoN hHeuO3qwg+hIR0x2BEfgwH18WHDGszisfBzCSAT3jltVNrE0KwKd08iBpfDbZUwS7OOn kcLN1EgL08iceU02aGQIqLLtCxXfantc8NQjJvSAoDbNY3vUkKxC8DEDSdGKAZXifU6v d4o0h1Oj+Sb/HjRQ6THx16SplG+cRQP0Dd7cELPN6k2CiKPiVrtSdqnGyJS+vne4TB8y 1BmEDiv0IN87DRZFoPLqza+aLg6Arb4DSazS0nIud8S9W4Buuk/qsezTgUOzonZ3HYXp 61uQ== X-Gm-Message-State: AOJu0YxWEINhRIkmIfGCpcJZVtKHMUbo8FF4NYpDX1lep8zyWquGFk9E C16rACAqH7dIBE1t/pakAXXZsES8zybA4DiCdtgTs9rUDdfQOHubzX/M1K/S1WTyXbfsC0woBE0 gFZqg/y9nssP+Rm07EoL9gf4FWk8= X-Google-Smtp-Source: AGHT+IGjoy/o1qJVNMc/KpxQNfeD/5M6a9n1owFcQ6lInMlod6AUBbphwOSyinYMdA/UAzC+qlPqmBscbV3xgoP4Cj8= X-Received: by 2002:a67:b40a:0:b0:478:6ced:3385 with SMTP id x10-20020a67b40a000000b004786ced3385mr7681128vsl.11.1712132900859; Wed, 03 Apr 2024 01:28:20 -0700 (PDT) MIME-Version: 1.0 References: <87msqbrga2.fsf@cbaines.net> In-Reply-To: <87msqbrga2.fsf@cbaines.net> From: Mikael Djurfeldt Date: Wed, 3 Apr 2024 10:28:09 +0200 Message-ID: Subject: Re: bug#70144: system* affects signal handlers To: Christopher Baines Content-Type: multipart/alternative; boundary="0000000000005d391506152d01ac" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 70144 Cc: Mikael Djurfeldt , 70144@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: , Reply-To: mikael@djurfeldt.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --0000000000005d391506152d01ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable system* temporarily re-binds signal handlers to prevent the child process from killing the parent. Thus, it is not thread safe with regard to SIGINT (or SIGQUIT if available). So, your code has a race condition with respect to the signal handler. This common resource can, in principle, be handled the usual way by, for example, utilizing a mutex: (use-modules (ice-9 threads)) (define sigint-mutex (make-mutex)) (define thread (call-with-new-thread (lambda () (with-mutex sigint-mutex (system* "echo" "foo"))))) (with-mutex sigint-mutex (sigaction SIGINT (lambda (sig) (peek "SIGINT handler") (exit 1))) (for-each (lambda _ (sleep 1)) (iota 30))) (join-thread thread) (display "normal exit\n") But if this was real code, another way would be to make sure that the code blocks are run in the order that you wish (which you did not want here since your very purpose was to provoke the collision of resources). I'm leaving this bug open. *Should* system* re-bind the signal handlers? Should it really protect itself from the child? If so, we should probably document this behaviour in the reference manual. Best regards, Mikael On Tue, Apr 2, 2024 at 4:28=E2=80=AFPM Christopher Baines wrote: > I've encountered a situation where signal handlers don't seem to > run. With the following program, sending it SIGINT won't trigger the > handler, however if you remove the system* call, then the handler will > run. > > (use-modules (ice-9 threads)) > > (call-with-new-thread > (lambda () > ;; Remove the following system* call to fix the handler > (system* "echo" "foo"))) > > (sigaction SIGINT > (lambda (sig) > (peek "SIGINT handler") > (exit 1))) > > (for-each > (lambda _ > (sleep 1)) > (iota 30)) > > (display "normal exit\n") > --0000000000005d391506152d01ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
system* temporarily re-binds signal handlers to preve= nt the child process from killing the parent. Thus, it is not thread safe w= ith regard to SIGINT (or SIGQUIT if available). So, your code has a race co= ndition with respect to the signal handler. This common resource can, in pr= inciple, be handled the usual way by, for example, utilizing a mutex:
=

(use-modules (ice-9 threads))

(define sigint-mut= ex (make-mutex))

(define thread
=C2=A0 (call-with-new-thread
= =C2=A0 =C2=A0(lambda ()
=C2=A0 =C2=A0 =C2=A0(with-mutex sigint-mutex
= =C2=A0 =C2=A0 =C2=A0 =C2=A0(system* "echo" "foo")))))
(with-mutex sigint-mutex
=C2=A0 (sigaction SIGINT
=C2=A0 =C2=A0= (lambda (sig)
=C2=A0 =C2=A0 =C2=A0 (peek "SIGINT handler")=C2=A0 =C2=A0 =C2=A0 (exit 1)))

=C2=A0 (for-each
=C2=A0 =C2=A0(l= ambda _
=C2=A0 =C2=A0 =C2=A0(sleep 1))
=C2=A0 =C2=A0(iota 30)))
(join-thread thread)

(display "normal exit\n")

But if this was real code, another way would be to make sur= e that the code blocks are run in the order that you wish (which you did no= t want here since your very purpose was to provoke the collision of resourc= es).

I'm leaving this bug open. *Should* syste= m* re-bind the signal handlers? Should it really protect itself from the ch= ild? If so, we should probably document this behaviour in the reference man= ual.

Best regards,
Mikael

On Tu= e, Apr 2, 2024 at 4:28=E2=80=AFPM Christopher Baines <mail@cbaines.net> wrote:
I've encountered a situation where si= gnal handlers don't seem to
run. With the following program, sending it SIGINT won't trigger the handler, however if you remove the system* call, then the handler will
run.

=C2=A0 (use-modules (ice-9 threads))

=C2=A0 (call-with-new-thread
=C2=A0 =C2=A0(lambda ()
=C2=A0 =C2=A0 =C2=A0;; Remove the following system* call to fix the handler=
=C2=A0 =C2=A0 =C2=A0(system* "echo" "foo")))

=C2=A0 (sigaction SIGINT
=C2=A0 =C2=A0 (lambda (sig)
=C2=A0 =C2=A0 =C2=A0 (peek "SIGINT handler")
=C2=A0 =C2=A0 =C2=A0 (exit 1)))

=C2=A0 (for-each
=C2=A0 =C2=A0(lambda _
=C2=A0 =C2=A0 =C2=A0(sleep 1))
=C2=A0 =C2=A0(iota 30))

=C2=A0 (display "normal exit\n")
--0000000000005d391506152d01ac-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 02 10:18:25 2024 Received: (at 70144) by debbugs.gnu.org; 2 May 2024 14:18:25 +0000 Received: from localhost ([127.0.0.1]:44082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s2XGT-0006Wz-Cj for submit@debbugs.gnu.org; Thu, 02 May 2024 10:18:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s2XGQ-0006Ws-O7 for 70144@debbugs.gnu.org; Thu, 02 May 2024 10:18:24 -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 1s2XFx-0007ec-Oc; Thu, 02 May 2024 10:17:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=S4c0rckFQVB4jrbkSdTQ4oX/pk0dlPzOlQuCYndT3Ks=; b=Nqx2FymKXgHlvEwoElvO /FmuK9PE21FUFmEpm/L1WMIu3iwcLl0MvfvIyzWT6PNQ3xIp1b82VNwjLw9NASLczRaTpqDsp1Lzj yecg+QErN+RFIMR3DXO+ylZL5xpYQp/UhAyHfX1TpMQzsCu+KJFo/lc6pnjiW2ulYaVBZwYTPOFVd nE5oeJVXCjqHzUs1MtfMhypRgH97tSIb5VL6MN0T0emCXKJjqwMEaXPvi7AZBwjpuCmO+Zwnf56L3 U89uviLPYkThSNj8IXzi7Z9No2QJotiq1ysKPGQLk/d3oFqO0W9qNrW8sMnIH9DS56FEkt9d6sWrh BdpYSFnPkQqPuQ==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Mikael Djurfeldt Subject: Re: bug#70144: system* affects signal handlers In-Reply-To: (Mikael Djurfeldt's message of "Wed, 3 Apr 2024 10:28:09 +0200") References: <87msqbrga2.fsf@cbaines.net> Date: Thu, 02 May 2024 16:17:49 +0200 Message-ID: <877cgcxppu.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70144 Cc: 70144@debbugs.gnu.org, Josselin Poiret , Christopher Baines 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 (---) Hi, Mikael Djurfeldt skribis: > system* temporarily re-binds signal handlers to prevent the child process > from killing the parent. Thus, it is not thread safe with regard to SIGINT > (or SIGQUIT if available). So, your code has a race condition with respect > to the signal handler. This common resource can, in principle, be handled > the usual way by, for example, utilizing a mutex: [...] > I'm leaving this bug open. *Should* system* re-bind the signal handlers? > Should it really protect itself from the child? If so, we should probably > document this behaviour in the reference manual. Unless I=E2=80=99m mistaken, we can remove the =E2=80=98scm_dynwind_sigacti= on=E2=80=99 calls from =E2=80=98scm_system_star=E2=80=99: now that we use =E2=80=98posix_spaw= n=E2=80=99, this is all taken care of. This can be seen by running: strace -o /tmp/log.strace -f guile -c '(system* "/bin/sh" "-c" "echo foo = $$")' =E2=80=A6 which shows pre-fork signal blocking (this is =E2=80=98internal_signal_block_all=E2=80=99 in spawni.c in glibc) followed,= in the child (PID 28592 here), by a long series of =E2=80=98sigaction=E2=80=99 calls to = reset handlers to their default behavior: --8<---------------cut here---------------start------------->8--- 28586 rt_sigprocmask(SIG_BLOCK, ~[], [], 8) =3D 0 28586 clone3({flags=3DCLONE_VM|CLONE_VFORK, exit_signal=3DSIGCHLD, stack=3D= 0x7f73b39b2000, stack_size=3D0x9000}, 88 28592 rt_sigprocmask(SIG_BLOCK, NULL, ~[KILL STOP], 8) =3D 0 28592 rt_sigaction(SIGHUP, NULL, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_fl= ags=3D0}, 8) =3D 0 28592 rt_sigaction(SIGHUP, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_flags=3D= SA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, NULL, 8) =3D 0 28592 rt_sigaction(SIGINT, NULL, {sa_handler=3DSIG_IGN, sa_mask=3D[], sa_fl= ags=3DSA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, 8) =3D 0 28592 rt_sigaction(SIGQUIT, NULL, {sa_handler=3DSIG_IGN, sa_mask=3D[], sa_f= lags=3DSA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, 8) =3D 0 28592 rt_sigaction(SIGILL, NULL, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_fl= ags=3D0}, 8) =3D 0 28592 rt_sigaction(SIGILL, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_flags=3D= SA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, NULL, 8) =3D 0 28592 rt_sigaction(SIGTRAP, NULL, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_f= lags=3D0}, 8) =3D 0 28592 rt_sigaction(SIGTRAP, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_flags= =3DSA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, NULL, 8) =3D 0 --8<---------------cut here---------------end--------------->8--- Josselin, can you confirm? Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Sun May 05 12:42:11 2024 Received: (at 70144) by debbugs.gnu.org; 5 May 2024 16:42:11 +0000 Received: from localhost ([127.0.0.1]:60596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3ewF-0001YF-AS for submit@debbugs.gnu.org; Sun, 05 May 2024 12:42:11 -0400 Received: from jpoiret.xyz ([206.189.101.64]:36960) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3ewA-0001Y9-Q9 for 70144@debbugs.gnu.org; Sun, 05 May 2024 12:42:09 -0400 Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id EE59F185460; Sun, 5 May 2024 16:41:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1714927301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QNWeSZNJSxuBGa61xr7/iBD+tryViSMC0RzxA267Vhg=; b=Pfzitw2pFeUuFb/KH0Kru+k+At0YWBq4IBAZmKTFTks0qxlz9SeRohzJruTgv/aWK+JeD3 APpDjx8dmqRo7uec258xI9y1Q6UXyLUcSCcKCzvlnCSDbPCU+iIRPBD/JobPWqazNKMWcm TROLim0rvCloPkId30A3IOsCXM1NRvXVfRAgEMFAxb+KJOGZ4mqff2w+m3OlK6P3q/JSg2 p4/r9owktVjjZJZvxNaYsjaDIlwBRQHhFtsQFVkqorAtYldVLaZJJKTwAJctNqFfDxUaWd 7M/evoOrsefuqEBMku1ECtHqY5U66g6w1unyfcTiCWjEXiC+VFBS6+y5KQZaXw== From: Josselin Poiret To: Ludovic =?utf-8?Q?Court=C3=A8s?= , Mikael Djurfeldt Subject: Re: bug#70144: system* affects signal handlers In-Reply-To: <877cgcxppu.fsf@gnu.org> References: <87msqbrga2.fsf@cbaines.net> <877cgcxppu.fsf@gnu.org> Date: Sun, 05 May 2024 18:41:38 +0200 Message-ID: <871q6g5hz1.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spamd-Bar: -- Authentication-Results: jpoiret.xyz; auth=pass smtp.auth=jpoiret@jpoiret.xyz smtp.mailfrom=dev@jpoiret.xyz X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 70144 Cc: 70144@debbugs.gnu.org, Christopher Baines 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo, Ludovic Court=C3=A8s writes: > Unless I=E2=80=99m mistaken, we can remove the =E2=80=98scm_dynwind_sigac= tion=E2=80=99 calls > from =E2=80=98scm_system_star=E2=80=99: now that we use =E2=80=98posix_sp= awn=E2=80=99, this is all taken > care of. > > This can be seen by running: > > strace -o /tmp/log.strace -f guile -c '(system* "/bin/sh" "-c" "echo fo= o $$")' > > =E2=80=A6 which shows pre-fork signal blocking (this is > =E2=80=98internal_signal_block_all=E2=80=99 in spawni.c in glibc) followe= d, in the child > (PID 28592 here), by a long series of =E2=80=98sigaction=E2=80=99 calls t= o reset > handlers to their default behavior: > > --8<---------------cut here---------------start------------->8--- > 28586 rt_sigprocmask(SIG_BLOCK, ~[], [], 8) =3D 0 > 28586 clone3({flags=3DCLONE_VM|CLONE_VFORK, exit_signal=3DSIGCHLD, stack= =3D0x7f73b39b2000, stack_size=3D0x9000}, 88 > 28592 rt_sigprocmask(SIG_BLOCK, NULL, ~[KILL STOP], 8) =3D 0 > 28592 rt_sigaction(SIGHUP, NULL, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_= flags=3D0}, 8) =3D 0 > 28592 rt_sigaction(SIGHUP, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_flags= =3DSA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, NULL, 8) =3D 0 > 28592 rt_sigaction(SIGINT, NULL, {sa_handler=3DSIG_IGN, sa_mask=3D[], sa_= flags=3DSA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, 8) =3D 0 > 28592 rt_sigaction(SIGQUIT, NULL, {sa_handler=3DSIG_IGN, sa_mask=3D[], sa= _flags=3DSA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, 8) =3D 0 > 28592 rt_sigaction(SIGILL, NULL, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_= flags=3D0}, 8) =3D 0 > 28592 rt_sigaction(SIGILL, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_flags= =3DSA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, NULL, 8) =3D 0 > 28592 rt_sigaction(SIGTRAP, NULL, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa= _flags=3D0}, 8) =3D 0 > 28592 rt_sigaction(SIGTRAP, {sa_handler=3DSIG_DFL, sa_mask=3D[], sa_flags= =3DSA_RESTORER, sa_restorer=3D0x7f73b432d2a0}, NULL, 8) =3D 0 > --8<---------------cut here---------------end--------------->8--- > > Josselin, can you confirm? Yes, I believe this is all taken care of by our use of posix_spawn (which was the point in the first place :) ). Best, =2D-=20 Josselin Poiret --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHEBAEBCAAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmY3tsIQHGRldkBqcG9p cmV0Lnh5egAKCRBQXkC5FhcaildpC/45yKKk5lGLESZTeGEeIJYMBW5ujQPyZ/nH 82n3rlKMD5mabZJkvKM5w8P7fORflPE85twvVPdt3Szs4Rzl8xiO/vevh6Rtxew5 QlaZJVlhQoAnCuwqo8OnADiBZeLI5E42bc6dU03LfEeSD+SwiZ2IQdrQYHJbS8sN sg/5MjUsKIJtAHouPFtBYUMkphsyGxjembMzmKOV+MjQ0KYN8zj9h5iqdIldjlvR jnDS2gMJtwQY0RKXN51qK1cT2G7bavV6xlJTv9fr067MXAQLGaF98Nsrl3P9cK7O Cl5KnnM1uvaHg9RV3quotHkhpQStE50ml9u25CjZqycIzaYzMEgOsJ0HRSj86Fyn HfYmOVtITPwpcrPYFD47sUfaan2aEF8c3z+a9xh1gG1qQAhZgDL4DDWYJhru+S4c bvC2W3P1WiDvoDyA5L0aTErOAOXbr9OjlNdRwFGCehHJY3EU+Xgc2cZaBmiwYuFH e3GJJyPN3c7C4IWtQqabyERHz/DZkuQ= =RTAu -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 06 06:01:28 2024 Received: (at 70144-done) by debbugs.gnu.org; 6 May 2024 10:01:29 +0000 Received: from localhost ([127.0.0.1]:36982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3vA0-0007aD-KZ for submit@debbugs.gnu.org; Mon, 06 May 2024 06:01:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3v9x-0007Zw-9a for 70144-done@debbugs.gnu.org; Mon, 06 May 2024 06:01: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 1s3v9R-0004fn-LC; Mon, 06 May 2024 06:00:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=p/ZgXOUUGeYyrA2yDuG1KEtPJmSlRHfdtuFpz4OPCKY=; b=hDvADwg1r6jLesL57Tih XlUY+v3sj280h/H90DeK349AZpPafMh+zlkyvHaM3iuoltch1ZiQBFejZhnbS6zMSzkymnElO/0cV ssjuJUJoSy/BQVqdXw9D950l9QJaKXn1OPrsiSZhdbOI4o0wmUjxufQfDBI0h2hpfb8bZDVgLzYOa cQ/AcT3qhER9xfdwyVpu3b+mkDdewMh7ma2IcVLDtf4/NeAwCtZpnFjSmzfu8fjiX4ee4sUOzoQn6 bN/CB98zrdcXLqCIIz9ukEZCTNg6fmTIFnmvg95GI0noeE9XIpJi7X1te2Dp4e4dkchN1q7olFvE7 Fgje9JgZg5jn0A==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Josselin Poiret Subject: Re: bug#70144: system* affects signal handlers In-Reply-To: <871q6g5hz1.fsf@jpoiret.xyz> (Josselin Poiret's message of "Sun, 05 May 2024 18:41:38 +0200") References: <87msqbrga2.fsf@cbaines.net> <877cgcxppu.fsf@gnu.org> <871q6g5hz1.fsf@jpoiret.xyz> Date: Mon, 06 May 2024 12:00:34 +0200 Message-ID: <87msp3l0ot.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70144-done Cc: Mikael Djurfeldt , 70144-done@debbugs.gnu.org, Christopher Baines 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 (---) Hi, Josselin Poiret skribis: > Yes, I believe this is all taken care of by our use of posix_spawn > (which was the point in the first place :) ). Yup! I pushed the fix as 4ae33f76d6b33ea0bedfa36050d44c88d08c2823. Thanks, Ludo=E2=80=99. From unknown Sun Aug 10 11:49:30 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 03 Jun 2024 11:24:15 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator