Re: Making type Datum be 8 bytes everywhere
От | Tomas Vondra |
---|---|
Тема | Re: Making type Datum be 8 bytes everywhere |
Дата | |
Msg-id | 87036018-8d70-40ad-a0ac-192b07bd7b04@vondra.me обсуждение исходный текст |
Ответ на | Re: Making type Datum be 8 bytes everywhere (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Making type Datum be 8 bytes everywhere
|
Список | pgsql-hackers |
Hi, While testing a different patch, I tried running with address sanitizer on rpi5, running the 32-bit OS (which AFAIK is 64-bit kernel and 32-bit user space). With that, stats_ext regression tests fail like this: extended_stats.c:1082:27: runtime error: store to misaligned address 0x036671dc for type 'Datum', which requires 8 byte alignment 0x036671dc: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e 7f 08 00 00 00 7f 7f 7f 7f ^ This happens because build_sorted_items() does palloc(), and then accesses the pointer as array of structs, with a Datum field. And it apparently expects the pointer to be a multiple of 8 bytes. Isn't that a bit strange, with 32-bit user space? The pointer is indeed a multiple of 4B, so maybe the expected alignment is wrong? I did try this on REL_18_STABLE, and that works just fine, so I believe it's about this commit. I also tried this on a i386 debian environment (more precisely, it's 32-bit chroot on 64-bit system, created using debootstrap). And that seems to work fine too ... It's entirely possible this is a rpi5-specific issue, or maybe a kernel issue. The last time we saw something similar weirdness, it turned out to be a long-standing kernel bug in move_pages(). But that affected the x86 systems too. FWIW this is how I run with address sanitizer: ./configure --enable-debug --enable-cassert \ CPPFLAGS="-O0 -fsanitize=alignment -fno-sanitize-recover=all -latomic" \ LDFLAGS="-fsanitize=alignment -latomic" regards -- Tomas Vondra
В списке pgsql-hackers по дате отправления: