From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11938 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.version-control.git Subject: Re: Re: Git 2.14.1: t6500: error during test on musl libc Date: Sat, 16 Sep 2017 12:13:22 -0400 Message-ID: <20170916161322.GX1627@brightrain.aerifal.cx> References: <59BB3E40.7020804@adelielinux.org> <20170915063740.GB21499@alpha.vpn.ikke.info> <20170915113011.emko6q5utb7x4bvu@sigill.intra.peff.net> <59BCAF81.3090206@adelielinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1505578424 22685 195.159.176.226 (16 Sep 2017 16:13:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Sep 2017 16:13:44 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeff King , Kevin Daudt , git@vger.kernel.org, musl@lists.openwall.com To: "A. Wilcox" Original-X-From: musl-return-11951-gllmg-musl=m.gmane.org@lists.openwall.com Sat Sep 16 18:13:39 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dtFir-0005e2-5A for gllmg-musl@m.gmane.org; Sat, 16 Sep 2017 18:13:37 +0200 Original-Received: (qmail 12016 invoked by uid 550); 16 Sep 2017 16:13:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11995 invoked from network); 16 Sep 2017 16:13:41 -0000 Content-Disposition: inline In-Reply-To: <59BCAF81.3090206@adelielinux.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11938 gmane.comp.version-control.git:331696 Archived-At: 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