简体   繁体   English

std :: vector reserve方法无法分配足够的内存

[英]std::vector reserve method fails to allocate enough memory

I have a buffer class in my C++ application as follows: 我的C ++应用程序中有一个缓冲类,如下所示:

class Buffer
{
    public:
    Buffer(size_t res): _rpos(0), _wpos(0)
    {
        _storage.reserve(res);
    }

    protected:
    size_t _rpos, _wpos;
    std::vector<uint8> _storage;
}

Sometimes using the constructor fails because its unable to allocate the required memory space. 有时使用构造函数失败,因为它无法分配所需的内存空间。 For example, once, calling the constructor with res = 37 caused a segfault with the following stack trace that i got from its core dump: 例如,曾经使用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>

I've compiled this application using GCC 4.4.2 as a 64 bit application and I'm using it in Debian 5 x64. 我使用GCC 4.4.2作为64位应用程序编译了这个应用程序,我在Debian 5 x64中使用它。

Any help is much appreciated. 任何帮助深表感谢。 Thanks 谢谢

Because the segfault is in malloc, most likely some other code has trashed the heap (ie written to parts of memory they do not own and are being used by the heap manager). 因为segfault是在malloc中,所以很可能其他一些代码已经破坏了堆(即写入它们不拥有并被堆管理器使用的内存部分)。

I recommend using Valgrind to find what code is trashing the heap. 我建议使用Valgrind来查找丢弃堆的代码。

If you can't use Valgrind to find out where your memory is corrupted because of the heavy load it implies, you can still test with lighter solutions. 如果您不能使用Valgrind来查明内存因其负载过重而损坏的位置,您仍然可以使用更轻的解决方案进行测试。

For server application where Valgrind was not applicable (because the platform was on Solaris 8), I had pretty good result with mpatrol ( http://mpatrol.sf.net ) but especially dmalloc ( http://dmalloc.com ). 对于Valgrind不适用的服务器应用程序(因为该平台在Solaris 8上),我使用mpatrol( http://mpatrol.sf.net )得到了相当不错的结果,但特别是dmalloc( http://dmalloc.com )。

To some extend, you can use them without recompiling (just relinking for dmalloc, library preloading for mpatrol). 在某种程度上,您可以使用它们而无需重新编译(只需重新链接dmalloc,mpatrol的库预加载)。 They'll replace the memory primitives to perform extra checks on the memory use (bad argument to those primitives, reading off-by-one, heap corruption, ...) Some of those checks will be triggered exactly when the problem occurs while others will be triggered a bit later than the actual bad code. 他们将替换内存原语以对内存使用执行额外检查(这些原语的错误参数,逐个读取,堆损坏......)其中一些检查将在问题发生时准确触发而其他检查将比实际的坏代码触发一点。 By tuning which checks are enabled, and when applicable the check frequency, you can run at almost full speed while performing basic checks. 通过调整启用哪些检查,以及适用的检查频率,您可以在执行基本检查时以几乎全速运行。

I recommend recompiling with dmalloc to get so called 'FUNC_CHECK', for me, this added a lot of accuracy in bug spotting with a negligible performance cost. 我建议使用dmalloc重新编译以获得所谓的'FUNC_CHECK',对我而言,这增加了很多错误定位的准确性,而且性能成本可以忽略不计。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM