On Mon, Jun 10, 2024 at 11:00:00AM +0300, Alexander Lakhin wrote:
> 10.06.2024 08:50, Michael Paquier wrote:
>> On Sun, Jun 09, 2024 at 03:00:00PM +0300, Alexander Lakhin wrote:
>>> 2)
>>> echo "
>>> select test_enc_conversion('\x8bc68bcf8b', 'gb18030', 'gb18030', false);
>>> " >> src/test/regress/sql/conversion.sql
>>> TESTS="conversion" make -s check-tests
>>>
>>> produces (under Valgrind):
>>> ==00:00:00:05.947 3320530== Invalid read of size 1
>>> ==00:00:00:05.947 3320530== at 0x6F21E5: pg_gb18030_mblen (wchar.c:1000)
>>> ==00:00:00:05.947 3320530== by 0x6F2BA0: pg_encoding_mblen (wchar.c:2072)
>>> ==00:00:00:05.947 3320530== by 0x6B4EAF: report_invalid_encoding (mbutils.c:1700)
>>> ==00:00:00:05.947 3320530== by 0x4867D3F: test_enc_conversion (regress.c:1154)
>>> ==00:00:00:05.947 3320530== by 0x3B9796: ExecInterpExpr (execExprInterp.c:764)
So, valgrind is noisy here because the incomplete byte sequence
\x8b passed as input of the function after a valid byte sequence
causes pg_encoding_mblen() to return 2, which is 1 byte passed the end
of the actual string. report_invalid_encoding() is careful to not
show any data passed in its input. I am not really sure that this is
worth bothering with here, TBH. As far as I know this is related to
the fact that we want test_enc_conversion() to be flexible enough to
accept any kind of input, working as a cheap shortcut to call these
internal encoding routines. What do you think?
> My Valgrind-testing procedure is:
> git apply .../install-vrunner.patch # use the attached
> CPPFLAGS="-Og -DUSE_VALGRIND" ./configure -q && make -j8 -s
Thanks. I was missing the -DUSE_VALGRIND.
--
Michael
