diff options
| author | Tomas Vondra <tomas.vondra@postgresql.org> | 2018-11-17 23:50:21 +0100 |
|---|---|---|
| committer | Tomas Vondra <tomas.vondra@postgresql.org> | 2018-11-18 00:08:19 +0100 |
| commit | bf070ce09e05943d6484de0ec17c7b02f2690a6d (patch) | |
| tree | 6268543eacfa6c42c99ed543cb8f248dccc2876d /src | |
| parent | 59f372e082e6564f4629dcbbc235c206e963814d (diff) | |
| download | postgresql-bf070ce09e05943d6484de0ec17c7b02f2690a6d.tar.gz postgresql-bf070ce09e05943d6484de0ec17c7b02f2690a6d.zip | |
Add valgrind suppressions for wcsrtombs optimizations
wcsrtombs (called through wchar2char from common functions like lower,
upper, etc.) uses various optimizations that may look like access to
uninitialized data, triggering valgrind reports.
For example AVX2 instructions load data in 256-bit chunks, and gconv
does something similar with 32-bit chunks. This is faster than accessing
the bytes one by one, and the uninitialized part of the buffer is not
actually used. So suppress the bogus reports.
The exact stack depends on possible optimizations - it might be AVX, SSE
(as in the report by Aleksander Alekseev) or something else. Hence the
last frame is wildcarded, to deal with this.
Backpatch all the way back to 9.4.
Author: Tomas Vondra
Discussion: https://www.postgresql.org/message-id/flat/90ac0452-e907-e7a4-b3c8-15bd33780e62%402ndquadrant.com
Discussion: https://www.postgresql.org/message-id/20180220150838.GD18315@e733.localdomain
Diffstat (limited to 'src')
| -rw-r--r-- | src/tools/valgrind.supp | 36 |
1 files changed, 36 insertions, 0 deletions
diff --git a/src/tools/valgrind.supp b/src/tools/valgrind.supp index af03051260b..fb08cf4fb87 100644 --- a/src/tools/valgrind.supp +++ b/src/tools/valgrind.supp @@ -212,3 +212,39 @@ Memcheck:Cond fun:PyObject_Realloc } + +# wcsrtombs uses some clever optimizations internally, which to valgrind +# may look like access to uninitialized data. For example AVX2 instructions +# load data in 256-bit chunks, irrespectedly of wchar length. gconv does +# somethink similar by loading data in 32bit chunks and then shifting the +# data internally. Neither of those actually uses the uninitialized part +# of the buffer, as far as we know. +# +# https://www.postgresql.org/message-id/90ac0452-e907-e7a4-b3c8-15bd33780e62@2ndquadrant.com + +{ + wcsnlen_optimized + Memcheck:Cond + ... + fun:wcsrtombs + fun:wcstombs + fun:wchar2char +} + +{ + wcsnlen_optimized_addr32 + Memcheck:Addr32 + ... + fun:wcsrtombs + fun:wcstombs + fun:wchar2char +} + +{ + gconv_transform_internal + Memcheck:Cond + fun:__gconv_transform_internal_utf8 + fun:wcsrtombs + fun:wcstombs + fun:wchar2char +} |