Date: Sat, 25 Feb 2012 09:10:04 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jilles Tjoelker <jilles@stack.nl> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r232108 - head/usr.bin/xargs Message-ID: <20120225084319.P3207@besplex.bde.org> In-Reply-To: <20120224210141.GA3223@stack.nl> References: <201202241235.q1OCZH2U059017@svn.freebsd.org> <20120225024051.C1150@besplex.bde.org> <20120224210141.GA3223@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>>> Modified: head/usr.bin/xargs/xargs.c
>>> ==============================================================================
>>> --- head/usr.bin/xargs/xargs.c Fri Feb 24 12:32:50 2012 (r232107)
>>> +++ head/usr.bin/xargs/xargs.c Fri Feb 24 12:35:17 2012 (r232108)
>>> @@ -608,8 +608,11 @@ waitchildren(const char *name, int waita
>>> * If utility signaled or exited with a value of 255,
>>> * exit 1-125.
>>> */
>
>> This comment didn't match the code before (the code always exited with
>> status 1), and is now further from matching the code.
>
>> This comment is hard to parse.
>
> It seems to repeat a POSIX requirement. I suppose it can go away as it
> doesn't really say anything the code doesn't say.
It's harder to parse than I thought :-). FreeBSD man pages are very
bad about distinguishing POSIX requirements from what the implementation
does (they mostly give the implementation behaviour without saying that).
Some source code says "POSIX requires...".
>> This misclassifies signal 127 due to the above bug.
>
>>> + if (WEXITSTATUS(status) == 255)
>>> + errx(1, "%s: exited with status 255, aborting", name);
>>> if (WEXITSTATUS(status))
>>> rval = 1;
>
>> 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.
I wonder how 0177 came to mean stopped. The kernel doesn't use _WSTOPPED,
and doesn't seem to use 0177 or 0x7f.
>> The messages have a grammar error (comma splice).
>
> GNU xargs has a semicolon instead of a comma. Is that better?
Yes.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120225084319.P3207>