Valgrind在为字符串赋值时报告内存泄漏。
我使用以下简单代码来测试Valgrind报告的内存泄漏。
/******************************************
* FILE: t3.c
* Compiled using : g++ -g t3.c -o t3
*
* $ g++ -v
* Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/specs
* Configured with: ./configure --prefix=/usr --infodir=/share/info --mandir=/share/man
* --enable-languages=c,c++ --with-system-zlib --program-suffix=-3.4 --enable-threads=posix
* Thread model: posix
* gcc version 3.4.6
******************************************/
#include <iostream>
#include <string>
using namespace std;
/**************************************************************
**************************************************************/
int main(int argc, char *argv[])
{
string test = "XXXXXXXXX";
cout << "this is a test " << test << endl;
exit(0);
}
我使用这个命令编译：
$ g++ -g t3.c -o t3
当我运行Valgrind时，它会在我尝试为字符串赋值时报告内存泄漏。我正在使用这个简单的测试来调查真实程序中的一些内存泄漏，似乎使用字符串会导致某种问题。
通过0x8048A6F：main（t3.c：23）是行：string test =“XXXXXXXXX”; 有人可以暗示这种奇怪的行为吗？
[enzo@P0101222 C]$ valgrind --leak-check=full ./t3
==3910== Memcheck, a memory error detector.
==3910== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==3910== Using LibVEX rev 1732, a library for dynamic binary translation.
==3910== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==3910== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==3910== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==3910== For more details, rerun with: -v
==3910==
this is a test XXXXXXXXX
==3910==
==3910== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1)
==3910== malloc/free: in use at exit: 102 bytes in 3 blocks.
==3910== malloc/free: 4 allocs, 1 frees, 126 bytes allocated.
==3910== For counts of detected errors, rerun with: -v
==3910== searching for pointers to 3 not-freed blocks.
==3910== checked 194,136 bytes.
==3910==
==3910== 16 bytes in 1 blocks are definitely lost in loss record 1 of 3
==3910== at 0x4017846: malloc (m_replacemalloc/vg_replace_malloc.c:149)
==3910== by 0x4018E05: realloc (m_replacemalloc/vg_replace_malloc.c:306)
==3910== by 0x41B441A: argz_append (in /lib/libc-2.2.5.so)
==3910== by 0x41593B9: __newlocale (in /lib/libc-2.2.5.so)
==3910== by 0x40E010B: std::locale::facet::_S_create_c_locale(__locale_struct*&, char const*, __locale_struct*) (c++locale.cc:99)
==3910== by 0x407EF6F: std::locale::facet::_S_initialize_once() (../../.././libstdc++-v3/src/locale.cc:172)
==3910== by 0x407EFB4: std::locale::facet::_S_get_c_locale() (../../.././libstdc++-v3/src/locale.cc:185)
==3910== by 0x407A422: std::ctype<char>::ctype(unsigned short const*, bool, unsigned) (/usr3/BUILD/gcc/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/ctype_noninline.h:104)
==3910== by 0x40801D5: std::locale::_Impl::_Impl(unsigned) (/usr3/BUILD/gcc/gcc-3.4.6/libstdc++-v3/libsupc++/new:92)
==3910== by 0x4080EED: std::locale::_S_initialize_once() (/usr3/BUILD/gcc/gcc-3.4.6/libstdc++-v3/libsupc++/new:92)
==3910== by 0x4080F84: std::locale::_S_initialize() (../../.././libstdc++-v3/src/locale_init.cc:155)
==3910== by 0x4080FE7: std::locale::locale() (../../.././libstdc++-v3/src/locale_init.cc:102)
==3910==
==3910==
==3910== 22 bytes in 1 blocks are possibly lost in loss record 2 of 3
==3910== at 0x4017C38: operator new(unsigned) (m_replacemalloc/vg_replace_malloc.c:163)
==3910== by 0x40BF2C4: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (/usr3/BUILD/gcc/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:81)
==3910== by 0x40C1CE4: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (/usr3/BUILD/gcc/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:150)
==3910== by 0x40C1E15: std::string::string(char const*, std::allocator<char> const&) (/usr3/BUILD/gcc/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1386)
==3910== **by 0x8048A6F: main (t3.c:23)**
==3910==
==3910== LEAK SUMMARY:
==3910== definitely lost: 16 bytes in 1 blocks.
==3910== **possibly lost: 22 bytes in 1 blocks.**
==3910== still reachable: 64 bytes in 1 blocks.
==3910== suppressed: 0 bytes in 0 blocks.
==3910== Reachable blocks (those to which a pointer was found) are not shown.
==3910== To see them, rerun with: --leak-check=full --show-reachable=yes
[enzo@P0101222 C]$
答案 0 :(得分：43)
因为你调用了exit(0)，所以永远不会调用字符串析构函数。只需使用return 0。
详细说明，std::string的构造函数分配堆内存来存储字符串，依赖于析构函数来释放该内存。如果在堆栈上声明一个字符串对象，当字符串对象超出范围时，将自动调用析构函数，从而释放内存。但exit实际上是一种C机制;它会立即退出程序而不执行堆栈展开，这意味着不会调用本地堆栈对象的C ++析构函数。
答案 1 :(得分：3)
如果你分配了五个字符串，你会得到五倍的内存泄漏，还是它仍然是相同的数量？如果它的数量相同，那么你可能根本就没有泄漏。有些库为内部簿记/效率/等等分配内存，直到valgrind停止查看之后才会释放内存。这些因内存泄漏而被捕获，因为您的程序导致了分配，但从未导致重新分配。如果它是数量的五倍，那么你的字符串实现可能有问题。我同意Charles Salvia的观点......再次使用return 0;而不是exit(0);再试一次，看看是否有任何变化。
答案 2 :(得分：3)
在我的一个计算机科学课程中，我们被告知Valgrind输出有关我们不应该担心的字符串的信息。这是他们为字符串提供的抑制文件： https://sites.google.com/site/complingfiles/files/string.supp
答案 3 :(得分：2)
尽管在计划结束时没有exit(0)，但我对std::string的误报有类似的问题。我与libstdc++静态链接。将链接选项切换为共享并使用GLIBCXX_FORCE_NEW进行编译会抑制警告。