Re: rhel8 test failure confirmation?

[Frederic Berat]

Hello,

I spent some more time on testing, and I could reproduce the issue on
Fedora rawhide, which gives more freedom for reproduction.

Regarding what I said earlier, since that wasn't clear enough, I couldn't
reproduce `make check` failures with the 1.16.5 official taball in a mock
environment, only with the trunk.
After few more hours, I could isolate 2 cases:
1) Random failures from multiple tests as stated earlier
2) Spurious failures of subobj.sh

Regarding 1), bisection led to 720a1153134b833de9298927a432b4ea266216fb
"m4: speed up filesystem modification checks". Whether it creates the
problem or simply reveals it is yet unclear. With this patch I could
reproduce multiple failures relatively easily (rarely more than one run).
Once reverted, the only test that fails from time to time on my side is
"subobj.sh" (twice out of ten trials). The amount of trials is probably not
enough, but based on previous observations, this patch looks to be a good
candidate for more investigations.

Regarding 2), that's less clear as this one fails less often, more time
would be needed to bisect it.

Fred.

On Sun, Mar 5, 2023 at 10:32 PM Bogdan <bogdro_rep@gmx.us> wrote:

> Karl Berry <karl@freefriends.org>, Sat Mar 04 2023 00:00:56 GMT+0100
> (Central European Standard Time)
> >      Note that 'config.h' is older (4 seconds) than './configure', which
> >      shouldn't be the case as it should get updated with new values.
> >
> > Indeed. That is the same sort of thing as I was observing with nodef.
> > But what (at any level) could be causing that to happen?
> > Files just aren't getting updated as they should be.
> >
> > I haven't yet tried older releases of automake to see if their tests
> > succeed on the systems that are failing now. That's next on my list.
>
> [...]
>
>
>   Another tip, maybe: cache again. When I compare which files are
> newer than the only trace file I get in the failing 'backcompat2' test
> ('autom4te.cache/traces.0'), I see that 'configure.ac' is older than
> this file in the succeeding run, but it's newer in the failing run.
> This could explain why 'configure' doesn't get updated to put new
> values in config.h (in my case) - 'autom4te' thinks it's up-to-date.
>   The root cause may be in 'autom4te', sub 'up_to_date':
>
>    # The youngest of the cache files must be older than the oldest of
>    # the dependencies.
>    # FIXME: These timestamps have only 1-second resolution.
>    # Time::HiRes fixes this, but assumes Perl 5.8 or later.
>
> (lines 913-916 in my version).
>
>   Perhaps 'configure.ac' in the case that fails is created "not late
> enough" (still within 1 second) when compared to the cache, and the
> cached values are taken, generating the old version of 'configure'
> which, in turn, generates old versions of the output files.
>
>   Still a guess, but maybe a bit more probable now.
>
>   Does it work when you add '-f' to '$AUTOCONF'? It does for me -
> again, about 20 sequential runs of the same set of tests and about 5
> parallel with 4 threads. Zero failures.
>   I'd probably get the same result if I did a 'rm -fr autom4te.cache'
> before each '$AUTOCONF' invocation.
>
>   If it does work for you, then maybe it would be better to add '-f'
> to the 'AUTOCONF' variable where it's defined? Tests with a single
> '$AUTOCONF' invocation won't notice (they will create their cache
> anyway), while tests with multiple calls can maybe get fixed all at once.
>
>   And I take back that the problem doesn't arise when I call the
> single test. I just wasn't "lucky enough". Got a failure now (without
> the fix), in the 7th attempt, while 40 or 60 (I did batches of 20)
> earlier succeeded (with the fix, of course).
>
>   So, maybe it's not a problem of a NEW system by itself, just a
> FASTER system + 1-second resolution in 'autom4te'.
>
> --
> 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
>
>
>