From owner-freebsd-bugs@FreeBSD.ORG Sun Apr 29 22:50:11 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C445B1065673 for ; Sun, 29 Apr 2012 22:50:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 960628FC15 for ; Sun, 29 Apr 2012 22:50:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3TMoBHd036682 for ; Sun, 29 Apr 2012 22:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3TMoBQb036681; Sun, 29 Apr 2012 22:50:11 GMT (envelope-from gnats) Date: Sun, 29 Apr 2012 22:50:11 GMT Message-Id: <201204292250.q3TMoBQb036681@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Jilles Tjoelker Cc: Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4() interface X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jilles Tjoelker List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 22:50:11 -0000 The following reply was made to PR kern/19402; it has been noted by GNATS. From: Jilles Tjoelker To: bug-followup@FreeBSD.org, netch@segfault.kiev.ua Cc: bde@freebsd.org Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4() interface Date: Mon, 30 Apr 2012 00:46:19 +0200 > [problems with signals 127 and 128] First, note that "clean" programs cannot use signals 127 and 128 because they do neither have a SIG* constant nor are in the range SIGRTMIN to SIGRTMAX. Therefore, I think it is inappropriate to make large changes to make them work. It suffices if wait4() and other interfaces cannot cause confusion. Because sh returns exit status 128+sig for signal sig, signal 128 cannot be represented in an 8-bit exit status and would have to be aliased to another signal if it is kept. The suggestion to modify wait4() ABI seems inappropriate for that reason. Another option is to modify the highest signal number accepted by interfaces (while leaving the size of sigset_t and the like unchanged). This effectively removes signals 127 and 128 from the system. One problem results when having posix_spawn() from an old libc reset all signals to default (by passing posix_spawnattr_setsigdefault() a sigfillset()'ed sigset_t and enabling the POSIX_SPAWN_SETSIGDEF flag in the posix_spawnattr_t). It will then attempt to set all signals from 1 to 128 to the default action and fail the entire spawn if sigaction() fails. This could be allowed by having certain calls (such as sigaction() with SIG_DFL) return success without doing anything for signals 127 and 128. This is likely to get messy. Alternatively, the default action for signals 127 and 128 could be changed to ignore (like SIGCHLD, SIGURG and SIGINFO), so that no process may terminate because of them. Processes can still send the signals and set handlers for them. Apart from the obvious effect that the process will not terminate when it receives such a signal without handling or masking it, FreeBSD also discards ignored signals even when they are masked (POSIX permits this). This could lead to unexpected results if a process is using sigwait() or a similar function. Yet another approach would modify the wait4() system call, changing signals 127 and 128 to something that does not cause confusion. This seems ugly. -- Jilles Tjoelker