summaryrefslogtreecommitdiff
path: root/src/tools/valgrind.supp
blob: 7ea464c809417feafa918b2ae2034df9479913eb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
# This is a suppression file for use with Valgrind tools.  File format
# documentation:
#	http://valgrind.org/docs/manual/mc-manual.html#mc-manual.suppfiles

# The libc symbol that implements a particular standard interface is
# implementation-dependent.  For example, strncpy() shows up as "__GI_strncpy"
# on some platforms.  Use wildcards to avoid mentioning such specific names.
# Avoid mentioning functions that are good candidates for inlining,
# particularly single-caller static functions.  Suppressions mentioning them
# would be ineffective at higher optimization levels.


# We have occasion to write raw binary structures to disk or to the network.
# These may contain uninitialized padding bytes.  Since recipients also ignore
# those bytes as padding, this is harmless.

{
	padding_pgstat_write
	Memcheck:Param
	write(buf)

	...
	fun:pgstat_write_statsfiles
}

{
	padding_XLogRecData_CRC
	Memcheck:Value8

	fun:pg_comp_crc32c*
	fun:XLogRecordAssemble
}

{
	padding_XLogRecData_write
	Memcheck:Param
	pwrite64(buf)

	...
	fun:XLogWrite
}

{
	padding_relcache
	Memcheck:Param
	write(buf)

	...
	fun:write_relcache_init_file
}

{
	padding_reorderbuffer_serialize
	Memcheck:Param
	write(buf)

	...
	fun:ReorderBufferSerializeTXN
}

{
	padding_twophase_prepare
	Memcheck:Param
	write(buf)

	...
	fun:EndPrepare
}


{
	padding_twophase_CRC
	Memcheck:Value8
	fun:pg_comp_crc32c*
	fun:EndPrepare
}

{
	padding_bootstrap_initial_xlog_write
	Memcheck:Param
	write(buf)

	...
	fun:BootStrapXLOG
}

{
	padding_bootstrap_control_file_write
	Memcheck:Param
	write(buf)

	...
	fun:WriteControlFile
	fun:BootStrapXLOG
}

{
	bootstrap_write_relmap_overlap
	Memcheck:Overlap
	fun:memcpy*
	fun:write_relmap_file
	fun:RelationMapFinishBootstrap
}


# gcc on ppc64 can generate a four-byte read to fetch the final "char" fields
# of a FormData_pg_cast.  This is valid compiler behavior, because a proper
# FormData_pg_cast has trailing padding.  Tuples we treat as structures omit
# that padding, so Valgrind reports an invalid read.  Practical trouble would
# entail the missing pad bytes falling in a different memory page.  So long as
# the structure is aligned, that will not happen.
{
	overread_tuplestruct_pg_cast
	Memcheck:Addr4

	fun:IsBinaryCoercibleWithCast
}

# Python's allocator does some low-level tricks for efficiency. Those
# can be disabled for better instrumentation; but few people testing
# postgres will have such a build of python. So add broad
# suppressions of the resulting errors.
# See also https://svn.python.org/projects/python/trunk/Misc/README.valgrind
{
   python_clever_allocator
   Memcheck:Addr4
   fun:PyObject_Free
}

{
   python_clever_allocator
   Memcheck:Addr8
   fun:PyObject_Free
}

{
   python_clever_allocator
   Memcheck:Value4
   fun:PyObject_Free
}

{
   python_clever_allocator
   Memcheck:Value8
   fun:PyObject_Free
}

{
   python_clever_allocator
   Memcheck:Cond
   fun:PyObject_Free
}

{
   python_clever_allocator
   Memcheck:Addr4
   fun:PyObject_Realloc
}

{
   python_clever_allocator
   Memcheck:Addr8
   fun:PyObject_Realloc
}

{
   python_clever_allocator
   Memcheck:Value4
   fun:PyObject_Realloc
}

{
   python_clever_allocator
   Memcheck:Value8
   fun:PyObject_Realloc
}

{
   python_clever_allocator
   Memcheck:Cond
   fun:PyObject_Realloc
}