0
Sur une machine Linux, exécutez ce script pour compiler une petite application C++ et l'exécuter sous valgrind:Stack alloués std :: rapports de chaîne comme fuite de mémoire par valgrind
#!/bin/bash
set -x -e
cd /tmp
cat > main.cpp <<EOF
#include <stdlib.h> // exit()
#include <string> // std::string
int main(int argc, char *argv[], char *const envp[])
{
std::string the_temp_string("bla bla bla");
exit(0);
return 0;
} // end main
EOF
lsb_release -d
/usr/bin/g++ --version
/usr/bin/g++ -MD -DDEBUG -g -ggdb -gstabs+ -O0 -fPIC -Wall -Werror -Wsynth -Wno-comment -Wreturn-type main.cpp -c -o main.o
/usr/bin/g++ -MD -DDEBUG -g -ggdb -gstabs+ -O0 -fPIC -Wall -Werror -Wsynth -Wno-comment -Wreturn-type main.o -L. -L/usr/lib64 -lstdc++ -o main.exe
rm -f valgrind.xml
/usr/bin/valgrind \
--xml=yes \
--xml-file=valgrind.xml \
--demangle=yes \
--gen-suppressions=all \
--track-origins=yes \
--leak-check=full \
--show-reachable=no \
--num-callers=40 \
./main.exe \
&& cat valgrind.xml
La sortie de ce qui précède pour mon la machine RHEL 6.8 donne:
+ cd /tmp
+ cat
+ lsb_release -d
Description: Red Hat Enterprise Linux Workstation release 6.8 (Santiago)
+ /usr/bin/g++ --version
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ /usr/bin/g++ -MD -DDEBUG -g -ggdb -gstabs+ -O0 -fPIC -Wall -Werror -Wsynth -Wno-comment -Wreturn-type main.cpp -c -o main.o
+ /usr/bin/g++ -MD -DDEBUG -g -ggdb -gstabs+ -O0 -fPIC -Wall -Werror -Wsynth -Wno-comment -Wreturn-type main.o -L. -L/usr/lib64 -lstdc++ -o main.exe
+ rm -f valgrind.xml
+ /usr/bin/valgrind --xml=yes --xml-file=valgrind.xml --demangle=yes --gen-suppressions=all --track-origins=yes --leak-check=full --show-reachable=no --num-callers=40 ./main.exe
+ cat valgrind.xml
<?xml version="1.0"?>
<valgrindoutput>
<protocolversion>4</protocolversion>
<protocoltool>memcheck</protocoltool>
<preamble>
<line>Memcheck, a memory error detector</line>
<line>Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.</line>
<line>Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info</line>
<line>Command: ./main.exe</line>
</preamble>
<pid>23040</pid>
<ppid>23010</ppid>
<tool>memcheck</tool>
<args>
<vargv>
<exe>/usr/bin/valgrind</exe>
<arg>--xml=yes</arg>
<arg>--xml-file=valgrind.xml</arg>
<arg>--demangle=yes</arg>
<arg>--gen-suppressions=all</arg>
<arg>--track-origins=yes</arg>
<arg>--leak-check=full</arg>
<arg>--show-reachable=no</arg>
<arg>--num-callers=40</arg>
</vargv>
<argv>
<exe>./main.exe</exe>
</argv>
</args>
<status>
<state>RUNNING</state>
<time>00:00:00:00.051 </time>
</status>
<status>
<state>FINISHED</state>
<time>00:00:00:00.298 </time>
</status>
<error>
<unique>0x6</unique>
<tid>1</tid>
<kind>Leak_PossiblyLost</kind>
<xwhat>
<text>36 bytes in 1 blocks are possibly lost in loss record 1 of 1</text>
<leakedbytes>36</leakedbytes>
<leakedblocks>1</leakedblocks>
</xwhat>
<stack>
<frame>
<ip>0x4A075FC</ip>
<obj>/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so</obj>
<fn>operator new(unsigned long)</fn>
<dir>/builddir/build/BUILD/valgrind-3.8.1/coregrind/m_replacemalloc</dir>
<file>vg_replace_malloc.c</file>
<line>298</line>
</frame>
<frame>
<ip>0x3138C9C3C8</ip>
<obj>/usr/lib64/libstdc++.so.6.0.13</obj>
<fn>std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&)</fn>
</frame>
<frame>
<ip>0x3138C9CDE4</ip>
<obj>/usr/lib64/libstdc++.so.6.0.13</obj>
</frame>
<frame>
<ip>0x3138C9CF32</ip>
<obj>/usr/lib64/libstdc++.so.6.0.13</obj>
<fn>std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)</fn>
</frame>
<frame>
<ip>0x40075C</ip>
<obj>/tmp/main.exe</obj>
<fn>main</fn>
</frame>
</stack>
<suppression>
<sname>insert_a_suppression_name_here</sname>
<skind>Memcheck:Leak</skind>
<sframe> <fun>_Znwm</fun> </sframe>
<sframe> <fun>_ZNSs4_Rep9_S_createEmmRKSaIcE</fun> </sframe>
<sframe> <obj>/usr/lib64/libstdc++.so.6.0.13</obj> </sframe>
<sframe> <fun>_ZNSsC1EPKcRKSaIcE</fun> </sframe>
<sframe> <fun>main</fun> </sframe>
<rawtext>
<![CDATA[
{
<insert_a_suppression_name_here>
Memcheck:Leak
fun:_Znwm
fun:_ZNSs4_Rep9_S_createEmmRKSaIcE
obj:/usr/lib64/libstdc++.so.6.0.13
fun:_ZNSsC1EPKcRKSaIcE
fun:main
}
]]>
</rawtext>
</suppression>
</error>
<errorcounts>
</errorcounts>
<suppcounts>
<pair>
<count>4</count>
<name>U1004-ARM-_dl_relocate_object</name>
</pair>
<pair>
<count>2</count>
<name>glibc-2.5.x-on-SUSE-10.2-(PPC)-2a</name>
</pair>
</suppcounts>
</valgrindoutput>
en appliquant la variable GLIBCXX_FORCE_NEW comme indiqué dans la réponse https://stackoverflow.com/a/7284726/257924 n'a eu aucun effet. Donc, ma question est la suivante: est-ce un bug dans valgrind, dans la version de la bibliothèque standard C++ sur cette machine, ou ma propre mauvaise compréhension de la façon dont la bibliothèque C++ se déchire à ::exit() temps d'appel? Ma pensée actuelle est que je peux juste le supprimer dans valgrind et passer à autre chose.
Note: Commentant l'appel à 'exit (0)' provoque l'erreur de valgrind disparaître. – bgoodr
Oui, lorsque vous commentez la sortie, les retours principaux et le destructeur de la chaîne std :: string sont appelés et libèrent la mémoire. Notez que les nouvelles versions de valgrind comprennent mieux l'accessibilité de std :: string (voir ma réponse ci-dessous) – phd