postgres.git / summary / log / commit / refs

commit    71b2951ccc433a6dd799efedff9f5927c32440f6
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 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
+}


[parent: 033d45a1008f]