Hi,
I've recently updated to Fedora 28, and in that environment I get quite
a few new valgrind issues (see the attached log).
Essentially, all the reports start with either
==5971== Invalid read of size 32
==5971== at 0x5957EB1: __wcsnlen_avx2 (in /usr/lib64/libc-2.27.so)
==5971== by 0x589E871: wcsrtombs (in /usr/lib64/libc-2.27.so)
==5971== by 0x5834000: wcstombs (in /usr/lib64/libc-2.27.so)
==5971== by 0x97DD82: wchar2char (pg_locale.c:1641)
or
==5971== Conditional jump or move depends on uninitialised value(s)
==5971== at 0x5822123: __gconv_transform_internal_utf8 (in
/usr/lib64/libc-2.27.so)
==5971== by 0x589E8A4: wcsrtombs (in /usr/lib64/libc-2.27.so)
==5971== by 0x5834000: wcstombs (in /usr/lib64/libc-2.27.so)
==5971== by 0x97DD82: wchar2char (pg_locale.c:1641)
or some other combination of that. In all cases the call stack is
wchar2char > wcstombs > wcsrtombs > something
I don't see these issues on the old (Fedora 26) environment, so it seems
to be caused by updating either gcc or glibc:
old system:
* glibc-2.25-13.fc26.x86_64
* gcc version 7.3.1 20180130 (Red Hat 7.3.1-2) (GCC)
new system:
* glibc-2.27-32.fc28.x86_64
* gcc version 8.2.1 20181011 (Red Hat 8.2.1-4) (GCC)
Valgrind is the same (valgrind-3.13.0) in both cases. I'm not sure if
it's due to some glibc changes, gcc generating different code, or
something else.
I've tried to look at wcsrtombs in glibc, but it's not particularly
readable piece of code. Also, my eyes bleed ... Thank god for pgindent!
I suspect it's either due to some glibc bug and/or gcc optimization that
ends up touching memory that was not actually initialized (judging by
__wcsnlen_avx2), or something like that. Not sure.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services