我在我的C ++应用程序中有一个缓冲区类，如下所示：
class Buffer { public: Buffer(size_t res): _rpos(0), _wpos(0) { _storage.reserve(res); } protected: size_t _rpos, _wpos; std::vector<uint8> _storage; } 有时使用构造函数失败，因为它无法分配所需的内存空间。 例如，一旦使用res = 37调用构造函数，会导致一个段错误，并从其核心转储中获得以下堆栈跟踪：
#0 0x00007f916a176ed5 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007f916a1783f3 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007f916a1b33a8 in ?? () from /lib/libc.so.6 No symbol table info available. #3 0x00007f916a1b8948 in ?? () from /lib/libc.so.6 No symbol table info available. #4 0x00007f916a1bb17c in ?? () from /lib/libc.so.6 No symbol table info available. #5 0x00007f916a1bca78 in malloc () from /lib/libc.so.6 No symbol table info available. #6 0x00007f916ac0c16d in operator new (sz=37) at ../../.././libstdc++-v3/libsupc++/new_op.cc:52 p = <value optimized out> #7 0x00000000004e3d11 in std::vector<unsigned char, std::allocator<unsigned char> >::reserve (this=0x7f911bc49cc0, __n=31077) at /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.2/../../../../include/c++/4.4.2/ext/new_allocator.h:89 __old_size = 0 __tmp = <value optimized out>
我已经使用GCC 4.4.2编译这个应用程序作为一个64位应用程序，我在Debian 5 x64中使用它。
任何帮助深表感谢。 谢谢
如果你不能使用Valgrind来找出你的内存由于其沉重的负载而损坏，你仍然可以用更轻的解决方案进行测试。
对于Valgrind不适用的服务器应用程序（因为该平台是在Solaris 8上），我用mpatrol（ http://mpatrol.sf.net ），但特别是dmalloc（ http://dmalloc.com ）有很好的结果。
在某种程度上，你可以在不重新编译的情况下使用它们（只需重新链接dmalloc，mpatrol的库预加载）。 他们将取代内存原语来对内存使用进行额外的检查（对那些原语的错误判断，逐个读取，堆损坏，…）其中一些检查将在发生问题时正好触发，而其他检查会比实际的错误代码晚一点被触发。 通过调整启用哪些检查以及检查频率（如果适用），可以在执行基本检查时以几乎全速运行。
我建议使用dmalloc进行重新编译，以获得所谓的“FUNC_CHECK”，对于我来说，这增加了很多错误发现的准确性，性能成本可以忽略不计。
由于segfault是在malloc中，很可能有其他代码已经抛出了堆（即写入到它们不拥有的堆内存管理器所使用的部分内存中）。
我建议使用Valgrind来查找哪些代码是垃圾堆。