Re: Non-reproducible AIO failure

Hi,

On 2025-06-10 17:28:11 +0300, Konstantin Knizhnik wrote:
> On 09/06/2025 2:05 am, Thomas Munro wrote:
> > On Sat, Jun 7, 2025 at 6:47 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > On 2025-06-06 14:03:12 +0300, Konstantin Knizhnik wrote:
> > > > There is really essential difference in code generated by clang 15 (working)
> > > > and 16 (not working).
> > > There also are code gen differences between upstream clang 17 and apple's
> > > clang, which is based on llvm 17 as well (I've updated the toolchain, it
> > > repros with that as well).
> > Just for the record, Apple clang 17 (self-reported clobbered version)
> > is said to be based on LLVM 19[1]. For a long time it was off by one
> > but tada now it's apparently two. Might be relevant if people are
> > comparing generated code up that close....

You've got to be kidding me. Because the world otherwise would be too easy, I
guess.

> > . o O (I wonder if one could corroborate that by running "strings" on
> > upstream clang binaries (as compiled by MacPorts/whatever) for each
> > major version and finding new strings, ie strings that don't appear in
> > earlier major versions, and then seeing which ones are present in
> > Apple's clang binaries... What a silly problem.)
> >
> > [1] https://en.wikipedia.org/wiki/Xcode#Xcode_15.0_-_16.x_(since_visionOS_support)
>
>
> Some updates: I was able to reproduce the problem at my Mac with old clang
> (15.0) but only with disabled optimization (CFLAGS=-O0).
> So very unlikely it is bug in compiler.

I was able to reproduce it with gcc, too.

> Why it is better reproduced in debug build? May be because of timing.

Code-gen wise the biggest change I see is that there is more stack spilling
due to assertion related code...

> Or may be because without optimization compiler is doing stupid things:
> loads all three bitfields from memory to register (one half word+one byte),
> then does some manipulations with this register and writes it back to
> memory. Can register somehow be clobbered between read and write (for
> example by signal handler)? Very unlikely...
> So still do not have any good hypothesis.
>
> But with bitfields replaced with uint8 the bug is not reproduced any more.
> May be just do this change (which seems to be good thing in any case)?

I've reproduced it without that bitfield, unfortunately :(.

Unfortunately my current set of debugging output seems to have prevented the
issue from re-occurring. Need to pare it down to re-trigger. But for me it
only reproduces relatively rarely, so paring down the debug output is a rather
slow process :(

This is really a peculiar issue. I've now ran 10s of thousands of non-macos
iterations, without triggering this or a related issue even once. The one good
news is that currently the regression tests are remarkably stable, I think in
the past I hardly could have run that many iterations without (independent)
failures.

Greetings,

Andres Freund