我的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中使用它。
非常感谢任何帮助。 感谢
答案 0 :(得分:8)
因为段错误是在malloc中,所以很可能其他一些代码已经破坏了堆(即写入它们不拥有并且正由堆管理器使用的内存部分)。
我建议使用Valgrind来查找丢弃堆的代码。
答案 1 :(得分:2)
如果您不能使用Valgrind来查明内存因其负载过重而损坏的位置,您仍然可以使用较轻的解决方案进行测试。
对于Valgrind不适用的服务器应用程序(因为该平台在Solaris 8上),我使用mpatrol(http://mpatrol.sf.net)得到了相当不错的结果,但特别是dmalloc(http://dmalloc.com)。
在某种程度上,您可以在不重新编译的情况下使用它们(只需重新链接dmalloc,mpatrol的库预加载)。他们将替换内存原语以对内存使用执行额外检查(这些原语的错误参数,逐个读取,堆损坏......)其中一些检查将在问题发生时准确触发而其他检查将比实际的坏代码触发一点。通过调整启用哪些检查,以及适用的检查频率,您可以在执行基本检查时几乎全速运行。
我建议使用dmalloc重新编译以获得所谓的'FUNC_CHECK',对我而言,这增加了很多错误定位的准确性,但性能成本可以忽略不计。