From: Rich Felker <dalias@libc.org>
To: "A. Wilcox" <awilfox@adelielinux.org>
Cc: Jeff King <peff@peff.net>, Kevin Daudt <me@ikke.info>,
git@vger.kernel.org, musl@lists.openwall.com
Subject: Re: Re: Git 2.14.1: t6500: error during test on musl libc
Date: Sat, 16 Sep 2017 12:13:22 -0400 [thread overview]
Message-ID: <20170916161322.GX1627@brightrain.aerifal.cx> (raw)
In-Reply-To: <59BCAF81.3090206@adelielinux.org>
On Fri, Sep 15, 2017 at 11:58:41PM -0500, A. Wilcox wrote:
> 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:
ISO C specifies very clearly what happens, in 7.21.6.2 The fscanf
function, paragraph 12:
c
Matches a sequence of characters of exactly the number
specified by the field width...
Note the word "exactly". Thus a read of fewer characters is not a
match.
There is an open glibc bug for this with classic Drepper behavior
until his departure, followed by acknowledgement of the bug, but no
further action I'm aware of:
https://sourceware.org/bugzilla/show_bug.cgi?id=12701
Any applications depending on the buggy glibc behavior should be
fixed.
Rich
next prev parent reply other threads:[~2017-09-16 16:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <59BB3E40.7020804@adelielinux.org>
[not found] ` <20170915063740.GB21499@alpha.vpn.ikke.info>
[not found] ` <20170915113011.emko6q5utb7x4bvu@sigill.intra.peff.net>
2017-09-16 4:58 ` A. Wilcox
2017-09-16 16:13 ` Rich Felker [this message]
2017-09-17 0:36 ` Junio C Hamano
2017-09-17 1:17 ` Szabolcs Nagy
2017-09-17 1:58 ` A. Wilcox
2017-09-17 3:16 ` Junio C Hamano
2017-09-17 3:38 ` A. Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170916161322.GX1627@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=awilfox@adelielinux.org \
--cc=git@vger.kernel.org \
--cc=me@ikke.info \
--cc=musl@lists.openwall.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).