Re: Valgrind failures caused by multivariate stats patch

Tomas Vondra <tomas.vondra@2ndquadrant.com>

From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>, Tomas Vondra <tv@fuzzy.cz>
Date: 2017-03-26T21:13:09Z
Lists: pgsql-hackers

Attachments

On 03/26/2017 08:47 PM, Andres Freund wrote:
> On 2017-03-26 20:38:52 +0200, Tomas Vondra wrote:
>> ...
>> Hmmm, so I have a theory about what's going on, but no matter what I do I
>> can't trigger these valgrind failures. What switches are you using to start
>> valgrind? I'm using this:
>>
>> valgrind --leak-check=no --undef-value-errors=yes \
>>   --expensive-definedness-checks=yes --track-origins=yes \
>>   --read-var-info=yes --gen-suppressions=all \
>>   --suppressions=src/tools/valgrind.supp --time-stamp=yes \
>>   --log-file=$HOME/pg-valgrind/%p.log --trace-children=yes \
>>   postgres --log_line_prefix="%m %p " --log_statement=all \
>>   --shared_buffers=64MB -D /home/user/tmp/data-valgrind 2>&1
>
> 	--quiet \
>          --error-exitcode=55 \
>          --suppressions=${PG_SRC_DIR}/src/tools/valgrind.supp \
>          --trace-children=yes --track-origins=yes --read-var-info=yes \
> 	 --num-callers=20 \
>          --leak-check=no \
> 	 --gen-suppressions=all \
>
> the error-exitcode makes it a whole lot easier to see an error, because
> it triggers a crash-restart cycle at backend exit ;)
>

OK, this did the trick. And just as I suspected, it seems to be due to 
doing memcpy+offsetof when serializing the statistic into a bytea. The 
attached patch fixes that for me. Can you test it on your build?

regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Fix uninitialized memory propagation mistakes