RE: [ANNOUNCE] Git v2.26.0 - Test Results NonStop Platform

RE: [ANNOUNCE] Git v2.26.0 - Test Results NonStop Platform

[Randall S. Becker]

On March 22, 2020 9:10 PM, Junio C Hamano wrote:
> The latest feature release Git v2.26.0 is now available at the usual places.  It
> is comprised of 504 non-merge commits since v2.25.0, contributed by 64
> people, 12 of which are new faces.

We had t0301 fail again. This is run entirely within bash as we gave up on ksh. I need some advice on what to do here. It does look like this is actually in git rather than the tests, based on below.

What is really strange is that the subtests are transiently failing and not the same test each time. I cannot get any consistency during test runs. I also do not see anything in the differences that might account for this, unless somehow the unicode length. I did revert and retried the test, which also resulted in transient failures. It all works fine when I use -x, so I can't shed light on it from there. An example of the failure is:

--- expect-stdout       2020-03-23 20:40:57 +0000
+++ stdout      2020-03-23 20:40:58 +0000
@@ -1,4 +1,4 @@
 protocol=https
 host=example.com
-username=askpass-username
-password=askpass-password
+username=store-user
+password=store-pass
not ok 21 - helper (cache) can forget host

We also had a hang in subtest 23 at

expecting success of 0301.23 'helper (cache) can forget user':
                check reject $HELPER <<-\EOF &&
                protocol=https
                host=example.com
                username=user1
                EOF
                check fill $HELPER <<-\EOF
                protocol=https
                host=example.com
                username=user1
                --
                protocol=https
                host=example.com
                username=user1
                password=askpass-password
                --
                askpass: Password for 'https://user1@example.com':
                EOF

++ check reject cache
++ credential_opts=
++ credential_cmd=reject
++ shift
++ for arg in "$@"
++ credential_opts=' -c credential.helper='\''cache'\'''
++ read_chunk
++ read line
++ case "$line" in
++ echo protocol=https
++ read line
++ case "$line" in
++ echo host=example.com
++ read line
++ case "$line" in
++ echo username=user1
++ read line
++ read_chunk
++ read line
++ read_chunk
++ read line
++ eval 'git  -c credential.helper='\''cache'\'' credential reject <stdin >stdout 2>stderr'
+++ git -c credential.helper=cache credential reject

Re: [ANNOUNCE] Git v2.26.0 - Test Results NonStop Platform

[Jeff King]

On Mon, Mar 23, 2020 at 05:25:25PM -0400, Randall S. Becker wrote:

> On March 22, 2020 9:10 PM, Junio C Hamano wrote:
> > The latest feature release Git v2.26.0 is now available at the usual places.  It
> > is comprised of 504 non-merge commits since v2.25.0, contributed by 64
> > people, 12 of which are new faces.
> 
> We had t0301 fail again. This is run entirely within bash as we gave
> up on ksh. I need some advice on what to do here. It does look like
> this is actually in git rather than the tests, based on below.
> 
> What is really strange is that the subtests are transiently failing
> and not the same test each time. I cannot get any consistency during
> test runs. I also do not see anything in the differences that might
> account for this, unless somehow the unicode length. I did revert and
> retried the test, which also resulted in transient failures. It all
> works fine when I use -x, so I can't shed light on it from there. An
> example of the failure is:

t0301 is about credential-cache, which involves daemonizing a process
and talking to it over a unix socket. I could very well believe that
there is some portability weirdness there on an exotic platform.

In particular:

> --- expect-stdout       2020-03-23 20:40:57 +0000
> +++ stdout      2020-03-23 20:40:58 +0000
> @@ -1,4 +1,4 @@
>  protocol=https
>  host=example.com
> -username=askpass-username
> -password=askpass-password
> +username=store-user
> +password=store-pass
> not ok 21 - helper (cache) can forget host

The point of that test is to tell the cache daemon to throw away the
entry, which means the next "fill" should have to resort to askpass. But
clearly it doesn't.

The "forgetting" is all internal to the daemon, so I don't think we'd
have a bug there. But is it possible that the client wasn't able to
contact the daemon? It would consider that a success (if there is no
daemon, then everything is already forgotten). If that happens
intermittently (when there actually _is_ a cache daemon there), it would
explain the behavior you're seeing.

Maybe try a patch like this:

diff --git a/credential-cache.c b/credential-cache.c
index 1cccc3a0b9..26baf74332 100644
--- a/credential-cache.c
+++ b/credential-cache.c
@@ -78,6 +78,8 @@ static void do_cache(const char *socket, const char *action, int timeout,
 			spawn_daemon(socket);
 			if (send_request(socket, &buf) < 0)
 				die_errno("unable to connect to cache daemon");
+		} else {
+			die_errno("cache daemon not available");
 		}
 	}
 	strbuf_release(&buf);

That will cause tests 1 and 14 of t0301 to fail consistently, but
possibly it could shed some light if other tests fail with it, too.

-Peff

RE: [ANNOUNCE] Git v2.26.0 - Test Results NonStop Platform

[Randall S. Becker]

On March 23, 2020 5:25 PM, I wrote:
> To: 'Junio C Hamano' <gitster@pobox.com>; 'git@vger.kernel.org'
> <git@vger.kernel.org>
> Cc: 'git-packagers@googlegroups.com' <git-packagers@googlegroups.com>
> Subject: RE: [ANNOUNCE] Git v2.26.0 - Test Results NonStop Platform
> 
> On March 22, 2020 9:10 PM, Junio C Hamano wrote:
> > The latest feature release Git v2.26.0 is now available at the usual
> > places.  It is comprised of 504 non-merge commits since v2.25.0,
> > contributed by 64 people, 12 of which are new faces.
> 
> We had t0301 fail again. This is run entirely within bash as we gave up on ksh.
> I need some advice on what to do here. It does look like this is actually in git
> rather than the tests, based on below.
> 
> What is really strange is that the subtests are transiently failing and not the
> same test each time. I cannot get any consistency during test runs. I also do
> not see anything in the differences that might account for this, unless
> somehow the unicode length. I did revert and retried the test, which also
> resulted in transient failures. It all works fine when I use -x, so I can't shed
> light on it from there. An example of the failure is:
> 
> --- expect-stdout       2020-03-23 20:40:57 +0000
> +++ stdout      2020-03-23 20:40:58 +0000
> @@ -1,4 +1,4 @@
>  protocol=https
>  host=example.com
> -username=askpass-username
> -password=askpass-password
> +username=store-user
> +password=store-pass
> not ok 21 - helper (cache) can forget host
> 
> We also had a hang in subtest 23 at
> 
> expecting success of 0301.23 'helper (cache) can forget user':
>                 check reject $HELPER <<-\EOF &&
>                 protocol=https
>                 host=example.com
>                 username=user1
>                 EOF
>                 check fill $HELPER <<-\EOF
>                 protocol=https
>                 host=example.com
>                 username=user1
>                 --
>                 protocol=https
>                 host=example.com
>                 username=user1
>                 password=askpass-password
>                 --
>                 askpass: Password for 'https://user1@example.com':
>                 EOF
> 
> ++ check reject cache
> ++ credential_opts=
> ++ credential_cmd=reject
> ++ shift
> ++ for arg in "$@"
> ++ credential_opts=' -c credential.helper='\''cache'\'''
> ++ read_chunk
> ++ read line
> ++ case "$line" in
> ++ echo protocol=https
> ++ read line
> ++ case "$line" in
> ++ echo host=example.com
> ++ read line
> ++ case "$line" in
> ++ echo username=user1
> ++ read line
> ++ read_chunk
> ++ read line
> ++ read_chunk
> ++ read line
> ++ eval 'git  -c credential.helper='\''cache'\'' credential reject <stdin >stdout
> 2>stderr'
> +++ git -c credential.helper=cache credential reject

I should have mentioned that we are currently on OpenSSL 1.0.2t. The 1.1.x series is not yet available.