Greetings, everyone!
While working on an extension, I've found myself using valgrind on a
32-bit OS (Debian 11)
and after executing any query (even 'select 1;') under valgrind I've
been shown the same error
everytime:
==00:00:00:18.109 2528== VALGRINDERROR-BEGIN
==00:00:00:18.109 2528== Use of uninitialised value of size 4
==00:00:00:18.109 2528== at 0x645B52: pg_comp_crc32c_sb8
(pg_crc32c_sb8.c:79)
==00:00:00:18.109 2528== by 0x24295F: XLogRecordAssemble
(xloginsert.c:780)
==00:00:00:18.109 2528== by 0x24295F: XLogInsert (xloginsert.c:459)
==00:00:00:18.109 2528== by 0x4B693B: LogCurrentRunningXacts
(standby.c:1099)
==00:00:00:18.109 2528== by 0x4B693B: LogStandbySnapshot
(standby.c:1055)
==00:00:00:18.109 2528== by 0x43BECF: BackgroundWriterMain
(bgwriter.c:336)
==00:00:00:18.109 2528== by 0x249D8A: AuxiliaryProcessMain
(bootstrap.c:446)
==00:00:00:18.109 2528== by 0x448B11: StartChildProcess
(postmaster.c:5445)
==00:00:00:18.109 2528== by 0x449F57: reaper (postmaster.c:2907)
==00:00:00:18.109 2528== by 0x486D587: ??? (in
/usr/lib/i386-linux-gnu/libpthread-2.31.so)
==00:00:00:18.109 2528== Uninitialised value was created by a stack
allocation
==00:00:00:18.109 2528== at 0x4B682F: LogStandbySnapshot
(standby.c:1018)
I've been able to reproduce this on branches from REL_11_STABLE up to
current master.
Valgrind version is 3.21.0.
I was wondering, why does this error occur only on 32-bit OS and not
64-bit?
I found three threads:
About issues with valgrind and padding -
https://www.postgresql.org/message-id/flat/1082573393.7010.27.camel%40tokyo
About sanitizers (and valgrind) in general -
https://www.postgresql.org/message-id/flat/20160321130850.6ed6f598%40fujitsu
About valgrind suppressions -
https://www.postgresql.org/message-id/flat/4dfabec2-a3ad-0546-2d62-f816c97edd0c%402ndQuadrant.com
and after reading those decided to look for existing valgrind
suppressions.
And I've found just what I was looking for:
{
padding_XLogRecData_CRC
Memcheck:Value8
fun:pg_comp_crc32c*
fun:XLogRecordAssemble
}
Supression for this (group of) function(s), but for 8-byte chunks of
memory.
So the suggestion is to add a suppression for 4-byte values in this
function.
The patch is attached.
Oleg Tselebrovskiy, Postgres Pro
