Hi, On 2022-03-03 15:31:51 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2022-03-03 14:00:14 -0500, Tom Lane wrote: > > For the buildfarm, I could enable it on flaviventris? That runs an > > experimental gcc, without optimization (whereas serinus runs with > > optimization). Which seems reasonable to combine with sanitizers? > > Dunno. I already found out that my Mac laptop (w/ clang 13) detects > the numeric.c problem but not any of the other ones. The messages > on RHEL8 cite where the system headers declare memcmp and friends > with "attribute nonnull", so I'm betting that Apple's headers lack > that annotation.
The sanitizers are documented to work best on linux... As flaviventris runs linux, so I'm not sure what your concern is? I think basically newer glibc versions have more annotations, so ubsan will have more things to fail against. So it'd be good to have a fairly regularly updated OS. > I also tried adding the various -m switches shown in Zhihong's > CFLAGS setting, but that still didn't repro the Alma warning > for me. The compilation flags make it look like it's from a run of yugabyte's fork, rather than plain postgres. The message says: src/backend/utils/adt/tid.c:112:16: runtime error: left shift of 65535 by 16 places cannot be represented in type 'int' Afaics that means bi_hi is 65535. So either we're dealing with a very large relation or BlockIdGetBlockNumber() is getting passed InvalidBlockNumber? It might be enough to do something like SELECT * FROM pg_class WHERE ctid = '(65535, 17)'; to trigger the problem? Greetings, Andres Freund
