Re: rhel8 test failure confirmation?

Karl Berry <[email protected]>, Wed Mar 01 2023 20:01:26 GMT+0100 
(Central European Standard Time)
> Does anyone have access to an RHEL 8-based machine? Alma Linux, Rocky Linux,
> original RHEL, or even (sort of) CentOS 8? It would be nice if someone
> could run a make check there (from automake dev).
>    git clone -q git://git.savannah.gnu.org/automake.git
>    cd automake
>    ./bootstrap
>    ./configure && make >&cm.out
>    make -j8 VERBOSE=1 check keep_testdirs=yes >&ch8.out
> (choose whatever -j value you like)


  Confirmed here as well (OpenMandriva with Autoconf 2.71). Tested 
Automake at the current 'master' and a little older branch.


> Even in a pristine environment, on a different physical machines, I find
> that a few tests fail, usually taken from the list below.  Not always
> the same tests fail, but I don't think it's directly related to
> parallelism.


  It's not. I run tests sequentially and also get failures. Randomly 
in time, but always in the same test (and just one).


> In the one I've looked into most, t/nodef.sh, it seems to be about disk
> writes not taking effect. That test runs the usual autotool sequence
> twice, both times writing to the same file named `output' and then
> grepping it, e.g.:
> grep 'DEFS.*-DVERSION=\\"UnIqUe' output && exit 1
> 
> If I put a sleep 1 between the two autotool invocations, it passes. If I
> don't, it fails, because the second grep reads the `output' file written
> by the first. Or so it seems. Which is crazy.


  Certainly looks that way, but for me, it's more like 
Autoconf/configure/config.status NOT updating the right files 
(config.h in my case).


> I could chalk it up to weird (extremely broken) hard disk behavior on
> one machine, but not two different machines with completely dissimilar
> hardware (including disks). It seems it must be in the os, in my case
> Alma Linux:
> $ grep ^VERSION= /etc/os-release
> VERSION="8.7 (Stone Smilodon)"
> (But I'd be very surprised if it is Alma-specific.)
> 
> All the tests pass fine on CentOS 7.


  This, along with my observation (below), MAY actually point to some 
issue with Autoconf. Old systems work, new don't.


> Sigh. --thanks, karl.
> 
> Approximate lists of tests that "usually" fail:
> FAIL: t/backcompat2.sh
> FAIL: t/backcompat3.sh
> FAIL: t/get-sysconf.sh
> FAIL: t/lex-depend.sh
> FAIL: t/nodef.sh
> FAIL: t/remake-aclocal-version-mismatch.sh
> FAIL: t/subdir-add2-pr46.sh
> FAIL: t/testsuite-summary-reference-log.sh


  When I run

make check TESTS='t/nodef.sh t/backcompat2.sh t/backcompat3.sh 
t/get-sysconf.sh t/lex-depend.sh t/remake-aclocal-version-mismatch.sh 
t/subdir-add2-pr46.sh t/testsuite-summary-reference-log.sh'

  I get failures in t/backcompat2.sh. Sometimes, like once-twice in 
ten runs.
  I've added a simple 'debug' in the form of the 'stat' command and:

--------------
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating config.h
config.status: config.h is unchanged
+ cat config.h
/* config.h.  Generated from config.h.in by configure.  */
/* #undef PACKAGE */
/* #undef VERSION */
+ LC_ALL=C
+ stat ./configure
   File: ./configure
   Size: 106382    	Blocks: 208        IO Block: 4096   regular file
Device: 8,6	Inode: 6328331     Links: 1
Access: (0700/-rwx------)  Uid: ( 1000/  bogdan)   Gid: ( 1006/  bogdan)
Access: 2023-03-02 21:42:36.138654005 +0100
Modify: 2023-03-02 21:42:36.251653430 +0100
Change: 2023-03-02 21:42:36.252653424 +0100
  Birth: 2023-03-02 21:42:36.138654005 +0100
+ LC_ALL=C
+ stat config.h
   File: config.h
   Size: 101       	Blocks: 8          IO Block: 4096   regular file
Device: 8,6	Inode: 6328337     Links: 1
Access: (0600/-rw-------)  Uid: ( 1000/  bogdan)   Gid: ( 1006/  bogdan)
Access: 2023-03-02 21:42:32.677671613 +0100
Modify: 2023-03-02 21:42:32.683671582 +0100
Change: 2023-03-02 21:42:32.693671531 +0100
  Birth: 2023-03-02 21:42:32.677671613 +0100
+ grep '^ *# *define  *PACKAGE  *"pkgname" *$' config.h
+ am_exit_trap 1
--------------


  Note that 'config.h' is older (4 seconds) than './configure', which 
shouldn't be the case as it should get updated with new values.

  What's funny, when I run just the failing test alone, it works 10 
times in a row. A "Schroedinger bug" - when you try to observe, you 
change the environment and the bug disappears :).
  I'll try to do some more digging later.

-- 
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org