bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #63307] make 4.4 passes ignored SIGPIPE on to children


From: Dmitry Goncharov
Subject: [bug #63307] make 4.4 passes ignored SIGPIPE on to children
Date: Sat, 5 Nov 2022 18:34:30 -0400 (EDT)

Follow-up Comment #6, bug #63307 (project make):

> If SIGIGN was ignored before make was started though, it should remain
ignored, even for make's children, see also
<https://lists.gnu.org/archive/html/bug-make/2022-11/msg00015.html> in reply
to Andreas Schwab's first patch. Correct me if I am wrong, but I think your
patch re-enables it in that case?

My patch causes the disposition of sigpipe to be set to SIG_DFL in the new
process. See https://pubs.opengroup.org/onlinepubs/9699919799/, specifically
"Signals set to be caught by the calling process image shall be set to the
default action in the new process image (see <signal.h>)."

This desire to have the default disposition is intentional. Some of the
reasons are explained in update 2. Other reasons are the desire to avoid
complexity in make. Especially when there is no clear need for that
complexity.


In regards to the specific impl of Andreas's 2nd patch there are 2 points.

1. That patch fails to restore the disposition in the case of make
re-executing itself (in order to read an updated makefile).
This could be fixed by calling sigaction before execve, but that'd not be
atomic.

2. That patch uses posix_spawnattr_setsigdefault to set the disposition for a
child process (when make uses posix_spawn). This fails the purpose of the
patch, if make was invoked with sigpipe disposition of SIG_HOLD.

Fixing those deficiencies is not that cheap. In the end, i didn't see any
benefit for make to go through that trouble of restoring sigpipe disposition
for its children and i proposed this simple fix.

Unlike attempts to restore, one nice property of the sighandler patch is that,
if more calls to exec are introduced to make, the patch will still work for
all of them.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63307>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]