[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Sep 2017 23:58:41 -0500
From: "A. Wilcox" <awilfox@...lielinux.org>
To: Jeff King <peff@...f.net>, Kevin Daudt <me@...e.info>
Cc: git@...r.kernel.org, musl@...ts.openwall.com
Subject: Re: Git 2.14.1: t6500: error during test on musl libc
On 15/09/17 06:30, Jeff King wrote:
> On Fri, Sep 15, 2017 at 08:37:40AM +0200, Kevin Daudt wrote:
>
>> On Thu, Sep 14, 2017 at 09:43:12PM -0500, A. Wilcox wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> Hi there,
>>>
>>> While bumping Git's version for our Linux distribution to 2.14.1, I've
>>> run in to a new test failure in t6500-gc.sh. This is the output of
>>> the failing test with debug=t verbose=t:
>>
>> This is a new test introduced by c45af94db
>> (gc: run pre-detach operations under lock, 2017-07-11) which was
>> included in v2.14.0.
>>
>> So it might be that this was already a problem for a longer time, only
>> just recently uncovered.
>
> The code change there is not all that big. Mostly we're just checking
> that the lock is actually respected. The lock code doesn't exercise libc
> all that much. It does use fscanf, which I guess is a little exotic for
> us. It's also possible that hostname() doesn't behave quite as we
> expect.
>
> If you instrument gc like the patch below, what does it report when you
> run:
>
> GIT_TRACE=1 ./t6500-gc.sh --verbose-only=8
>
> I get:
>
> [...]
> trace: built-in: git 'gc' '--auto'
> Auto packing the repository in background for optimum performance.
> See "git help gc" for manual housekeeping.
> debug: gc lock already held by $my_hostname
> [...]
>
> If you get "acquired gc lock", then the problem is in
> lock_repo_for_gc(), and I'd suspect some problem with fscanf or
> hostname.
>
> -Peff
Hey there Peff,
What a corner-y corner case we have here. I believe the actual error is
in the POSIX standard itself[1], as it is not clear what happens when
there are not enough characters to 'fill' the width specified with %c in
fscanf:
> c
> Matches a sequence of bytes of the number specified by the field
> width (1 if no field width is present in the conversion
> specification).
I've tested a number of machines:
* OpenBSD 5.7/amd64
* NetBSD 7.0/i386
* FreeBSD 12/PowerPC
* glibc/arm
* Windows 7 with Microsoft Visual C++ 2013
All of them will allow a so-called "short read" and give you as many
characters as they can, treating the phrase "a sequence of bytes of the
number specified" as meaning "*up to* the number".
The musl libc treats this phrase as meaning "*exactly* the number", and
fails if it cannot give you exactly the number you ask.
IBM z/OS explicitly states in their documentation[2]:
> Sequence of one or more characters as specified by field width
And Microsoft similarly states[3]:
> The width field is a positive decimal integer controlling the maximum
> number of characters to be read for that field. No more than width
> characters are converted and stored at the corresponding argument.
> Fewer than width characters may be read if a whitespace character
> (space, tab, or newline) or a character that cannot be converted
> according to the given format occurs before width is reached.
While musl's reading is correct from an English grammar point of view,
it does not seem to be how any other implementation has read the standard.
However! It gets better.
The ISO C standard, committee draft version April 12, 2011, states[4]:
> c Matches a sequence of characters of exactly the number specified
> by the field width (1 if no field width is present in the directive).
Since "[t]his volume of POSIX.1-2008 defers to the ISO C standard", it
stands to reason that this is the intended meaning and behaviour. Thus
meaning that literally every implementation, with the exception of the
musl libc, is breaking the ISO C standard.
Since Git is specifically attempting to read in a host name, there may
be a solution: while 'c' guarantees that any byte will be read, and 's'
will skip whitespace, RFCs 952 and 1123 §2.1[5] specify that a network
host name must never contain whitespace. IDNA2008 §2.3.2.1[6] (and
IDNA2003 before it) specifically removes ASCII whitespace characters
from the valid set of Unicode codepoints for an IDNA host name[7].
Additionally, the buffer `locking_host` is already defined as an array
of char of size HOST_NAME_MAX + 1, and the width specifier in fscanf is
specified as HOST_NAME_MAX. Therefore, it should be safe to change git
to use the 's' type character. Additionally, I can confirm that this
change (patch attached) allows the Git test suite to pass on musl.
I hope this message is informative. This was an exhausting, but
necessary, exercise in trying to ensure code correctness.
I am cc'ing the musl list so that this information may live there as
well, in case someone in the future has issues with the 'c' type
specifier with fscanf on musl.
All the best,
--arw
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fscanf.html
[2]:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/fscanf.htm
[3]: https://msdn.microsoft.com/en-us/library/xdb9w69d.aspx
[4]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
[5]: https://tools.ietf.org/html/rfc1123#section-2.1
[6]: https://tools.ietf.org/html/rfc5890#section-2.3.2.1
[7]: http://unicode.org/faq/idn.html#33
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
View attachment "0001-gc-use-s-type-character-for-fscanf.patch" of type "text/x-patch" (1117 bytes)
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
