aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorTomas Vondra <tomas.vondra@postgresql.org>2018-11-17 23:50:21 +0100
committerTomas Vondra <tomas.vondra@postgresql.org>2018-11-17 23:50:21 +0100
commitd3bbc4b96a5b4d055cf636596c6865913a099929 (patch)
treeadd420291b6045de10c7478c76ee1ccca8438b26 /src
parent37afc079abe1986b4af94aa8ec28cefd663aaae6 (diff)
downloadpostgresql-d3bbc4b96a5b4d055cf636596c6865913a099929.tar.gz
postgresql-d3bbc4b96a5b4d055cf636596c6865913a099929.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.supp36
1 files changed, 36 insertions, 0 deletions
diff --git a/src/tools/valgrind.supp b/src/tools/valgrind.supp
index ec47a228ae5..85122315393 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
+}