git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [musl] Re: Git 2.14.1: t6500: error during test on musl libc

From
RFRich Felker <dalias@libc.org>
Date
Sep 16, 2017, 16:13 UTC
Message-ID
<20170916161322.GX1627@brightrain.aerifal.cx>
In-Reply-To
<59BCAF81.3090206@adelielinux.org>
On Fri, Sep 15, 2017 at 11:58:41PM -0500, A. Wilcox wrote:
Show 53 quoted lines
> 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
Previous: A. WilcoxNext: Junio C Hamano
Message 6 of 11 in “Git 2.14.1: t6500: error during test on musl libc”
  1. A. WilcoxSep 15, 2017
  2. Kevin DaudtSep 15, 2017
  3. Kevin DaudtSep 15, 2017
  4. Jeff KingSep 15, 2017
  5. A. WilcoxSep 16, 2017
  6. Rich FelkerSep 16, 2017
  7. Junio C HamanoSep 17, 2017
  8. Szabolcs NagySep 17, 2017
  9. A. WilcoxSep 17, 2017
  10. Junio C HamanoSep 17, 2017
  11. A. WilcoxSep 17, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.