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
|
# Below is a temporary patch (slightly modified) from
# 345307 - Warning about "still reachable" memory when using libstdc++ from gcc 5
# This patch is not needed anymore if libstdc++ provides __gnu_cxx::__freeres
# but we still need to ignore these allocations during the leak_cpp_interior
# to have the test behaviour not depending on libstdc++ version.
# Some programs are using the C++ STL and string classes.
# Valgrind reports 'still reachable' memory leaks involving these classes
# at the exit of the program, but there should be none.
#
# Many implementations of the C++ standard libraries use their own memory
# pool allocators. Memory for quite a number of destructed objects is not
# immediately freed and given back to the OS, but kept in the pool(s) for
# later re-use. The fact that the pools are not freed at the exit of the
# program cause Valgrind to report this memory as still reachable.
#
# The behavior not to free pools at the exit could be called a bug of the
# library though.
#
# Using GCC, you can force the STL to use malloc and to free memory as soon
# as possible by globally disabling memory caching. Beware! Doing so will
# probably slow down your program, sometimes drastically.
#
# There are other ways to disable memory pooling: using the malloc_alloc
# template with your objects (not portable, but should work for GCC) or
# even writing your own memory allocators. But beware: allocators belong
# to the more messy parts of the STL and people went to great lengths to
# make the STL portable across platforms. Chances are good that your
# solution will work on your platform, but not on others.
#
# 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
# at 0x4C28D06: malloc (vg_replace_malloc.c:299)
# by 0x50C317F: ??? (in /usr/lib64/libstdc++.so.6.0.21)
# by 0x400F759: call_init.part.0 (dl-init.c:72)
# by 0x400F86A: call_init (dl-init.c:30)
# by 0x400F86A: _dl_init (dl-init.c:120)
# by 0x4000CB9: ??? (in /usr/lib64/ld-2.22.so)
#
# HEAP SUMMARY:
# in use at exit: 72,704 bytes in 1 blocks
# total heap usage: 4 allocs, 3 frees, 72,864 bytes allocated
#
# LEAK SUMMARY:
# definitely lost: 0 bytes in 0 blocks
# indirectly lost: 0 bytes in 0 blocks
# possibly lost: 0 bytes in 0 blocks
# still reachable: 72,704 bytes in 1 blocks
# suppressed: 0 bytes in 0 blocks
# All the following suppressions are variants of
# _dl_init -> call_init which calls the DT_INIT_ARRAY functions
{
malloc-leaks-cxx-stl-string-classes
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
obj:*lib*/libstdc++.so*
fun:call_init.part.0
fun:call_init
fun:_dl_init
obj:*lib*/ld-2.*.so
}
{
malloc-leaks-cxx-stl-string-classes-2
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
obj:*lib*/libstdc++.so*
fun:call_init.part.0
fun:_dl_init
obj:*lib*/ld-2.*.so
}
{
malloc-leaks-cxx-stl-string-classes-debug
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
fun:pool
fun:__static_initialization_and_destruction_0
fun:_GLOBAL__sub_I_eh_alloc.cc
fun:call_init.part.0
fun:call_init
fun:_dl_init
obj:*lib*/ld-2.*.so
}
{
malloc-leaks-cxx-stl-string-classes-debug2
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
obj:*
fun:call_init
fun:_dl_init
fun:_dl_start_user
}
|
