Date: Mon, 27 Feb 2012 00:25:40 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r232108 - head/usr.bin/xargs Message-ID: <20120226232540.GA34962@stack.nl> In-Reply-To: <20120225084319.P3207@besplex.bde.org> References: <201202241235.q1OCZH2U059017@svn.freebsd.org> <20120225024051.C1150@besplex.bde.org> <20120224210141.GA3223@stack.nl> <20120225084319.P3207@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 25, 2012 at 09:10:04AM +1100, Bruce Evans wrote: > On Fri, 24 Feb 2012, Jilles Tjoelker wrote: > > > On Sat, Feb 25, 2012 at 04:27:35AM +1100, Bruce Evans wrote: > > ... > >> Utilities are quite broken near here too: > >> - under -current: > >> - utilities still don't support signals >= 32, but give better error > >> messages. > > > > kill(1) (both /bin/kill and the 9.x/10.x sh builtin) has passed > > arbitrary signal numbers to kill(2) for quite a while. > > Apparently I got confused by testing several versions. In -current, > the bugs are just that: > - bash-4.2 builtin kill doesn't understand signals >= 32, despite > supposedly being configured for FreeBSD > - bash-4.2 prints confusing termination messages which made me think > that /bin/kill didn't work: > - for signal 127, it prints "Stopped ..." > - for signal 126, it prints "Unknown signal: 126". I didn't notice > this was printed by bash(1) and not by kill(1). > A bug in builtin kill turned up: with kill(1), both bash and sh print > the termination message immediately, with builtin kill neither prints > it until a newline is entered. That's not a bug, but a normal race condition. With external kill, the kill process usually takes long enough to shut down and be waited for that the kill victim will have terminated too. With builtin kill, the shell proceeds very quickly and often the kill victim will not have terminated yet. > >> Neither WIFSTOPPED() nor WIFEXITED() are tested, so the result of the > >> misclassification is turning signal 127 into a normal exit with status > >> 0. A normal WIFSTOPPED() should not get here, else job control would > >> just break xargs, so the bug can probably be worked around by turning > >> WIFSTOPPED() into WIFSIGNALED() here, or just blindly using WTERMSIG() > >> != 0 to classify signals. > > I don't think xargs should work around that bug, particularly not by > > introducing unspecified behaviour (the value of WTERMSIG(x) when > > !WIFSIGNALED(x)). > OK. So it needs to be disallowed in the kernel. Hmm. The kernel allows 0 <= sig <= 128 (_SIG_MAXSIG). It also allows signals 33..64 which do not have a documented meaning. I wonder what will break if I change _SIG_MAXSIG to 126. This will disallow all operations on signals 127 and 128 and change the sigacts structure. Alternatively, the check in sys_kill() and friends could be tightened. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120226232540.GA34962>