Re: rhel8 test failure confirmation?

[Frederic Berat]

Oh, and I forgot, regarding autoconf: the RHEL 8 image I tested with had
autoconf 2.69. Failures could be detected with automake trunk, not with
official tarball (at least so far).

On Mon, Mar 6, 2023 at 11:19 PM Frederic Berat <fberat@redhat.com> wrote:

> 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
>>
>>
>>