Re: BUG #15121: Multiple UBSAN errors

Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> On 03/18/2018 08:59 PM, PG Bug reporting form wrote:
>> Building current trunk with -fsanitize=undefined I see following errors with
>> make check:

>> pg_crc32c_sse42.c:37:18: runtime error: load of misaligned address
>> 0x7fffffffd484 for type 'const uint64', which requires 8 byte alignment
>> 0x7fffffffd484: note: pointer points here

> This comes from this call in pg_comp_crc32c_sse42
> crc = (uint32) _mm_crc32_u64(crc, *((const uint64 *) p));
> ...
> So, not a bug.

Agreed. That's Intel-only code so it doesn't need to be strict
about alignment.

>> arrayfuncs.c:3740:17: runtime error: member access within misaligned address
>> 0x0000028b937c for type 'struct ExpandedObjectHeader', which requires 8 byte
>> alignment

> Again, the line numbers don't really match the code I have, but I guess
> it's the same issue as for pg_comp_crc32c_sse42. This is apparently
> related to array serialization, and I guess we have a compact structure
> (intentionally, to make it smaller), and we accept the unaligned access.

No, there's no intentional misalignment in the array stuff; if there
were, it'd fail on alignment-picky hardware.

What I think might be happening is that the compiler is taking the
fact that the pointer is declared as AnyArrayType *, where

typedef union AnyArrayType
{
ArrayType flt;
ExpandedArrayHeader xpn;
} AnyArrayType;

to assume that the pointer must be aligned on an 8-byte boundary because
ExpandedArrayHeader would require that, even if we're only accessing the
"flt" member. Maybe that's a live problem, though we've seen no related
trouble reports. It'd require the compiler to generate 8-byte-aligned
instructions for accessing the ArrayType header, which doesn't seem all
that probable.

regards, tom lane