postgres.git / summary / log / commit / refs

commit    f57b94d9d0bbf42a18690d820f884dc0fc6bf79e
Author:   Tomas Vondra <tomas.vondra@postgresql.org>
Date:     Sat Nov 17 22:50:21 2018 +0000
First released in: master (reverted before release), REL9_4_STABLE (reverted before release), REL9_5_STABLE (reverted before release), REL9_6_STABLE (reverted before release), REL_10_STABLE (reverted before release), REL_11_STABLE (reverted before release)
Reverted by: 6f090c1d8d22 (in 9.4.21), 7990922413ca (in 9.5.16), 058e2757b9bf (in 9.6.12), 6831aba29f5b (in 10.7), 0ec29785c52c (in 11.2), d6ef7fe75c1f (in 12.0)

    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


 src/tools/valgrind.supp | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/src/tools/valgrind.supp b/src/tools/valgrind.supp
index f0436789275..0c3cbbedafe 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
+}


[parent: 44dc82690d4e]