Subject: Re: valgrind issues on Fedora 28
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
References: <90ac0452-e907-e7a4-b3c8-15bd33780e62@2ndquadrant.com>
 <20181106173500.ojw6btsxy3oj5jwz@alap3.anarazel.de>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <fbfbd980-5011-9a1d-3573-e64cabb533c8@2ndquadrant.com>
Date: Tue, 6 Nov 2018 18:49:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20181106173500.ojw6btsxy3oj5jwz@alap3.anarazel.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/6/18 6:35 PM, Andres Freund wrote:
> On 2018-11-06 18:24:55 +0100, Tomas Vondra wrote:
>> 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)
> 
> 
> I think this isn't actually a bug, just a missing suppression. The avx2
> code uses instructions to scan for 0 bytes in multiple bytes at the same
> time. Therefore it can encounter a byte marked as undefined, even if it
> never actually uses that value.
> 

OK, my thoughts exactly.

>> 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 think I came to the same conclusion here, but I'm not quite sure.
> 

Looking at gconv code at [1], it seems it's reading the data as int32 
values and using shifts to extract individual bytes. I'm pretty sure 
this confuses valgrind so it thinks it's accessing all the bytes.

[1] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=iconv/gconv_simple.c;h=506c92caf228d61f92986c39a2ddf9c0a134b4c0;hb=HEAD

> FWIW, I've supressed these on my valgrind animal a while ago.
> 

OK, I propose to add these suppressions into the current list.


regards

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