Re: [PATCH] t1092: use GIT_PROGRESS_DELAY for consistent results

From: Taylor Blau <me@ttaylorr.com>
Date: May 25, 2021, 21:49 UTC
Message-ID: <YK1w7TPnH9CB0haj@nand.local>
In-Reply-To: <xmqq1r9uee3r.fsf@gitster.g>

On Wed, May 26, 2021 at 05:46:16AM +0900, Junio C Hamano wrote:

Show 8 quoted lines

> Well, not so well X-<.  It seems that some builds are not happy with
> this change.  See https://github.com/git/git/actions/runs/876229761
> specifically these two:
>
>     https://github.com/git/git/runs/2669177395?check_suite_focus=true#step:7:3549
>     https://github.com/git/git/runs/2669080101?check_suite_focus=true#step:6:988
>
> I suspect that it has something to do with 32-bit platforms?

Thanks. Of course, redirecting stderr into a file and halting after we get a non-zero exit code makes this pretty hard to debug from that output alone, but this is pretty easily reproducible on a 32-bit Docker image:

    root@99cfe0d56673:/git-master# getconf LONG_BIT
    32
    root@99cfe0d56673:/git-master# GIT_PROGRESS_DELAY=-1 ./bin-wrappers/git status
    fatal: failed to parse GIT_PROGRESS_DELAY

Looking more closely in a debugger shows that we're failing because of this check in 'config.c:git_parse_unsigned()':

    if (unsigned_mult_overflows(factor, val) ||
        factor * val > max) {
          errno = ERANGE;
          return 0;
    }

unsigned_mult_overflows() doesn't trigger regardless of architecture, since even though val is large, factor is 1, so factor * val == val. But val is much larger than max, so we fail there. 'max' is just 'maximum_unsigned_value_of_type(long)', or 2^32-1, while val is 2^64-1.

Thanks, Taylor