当我将类型的对象推_Tp回时std::vector，出现段故障信号SIGSEGV，并template new_allocator<_Tp>在以下代码段的结尾处返回：
pointer
allocate(size_type __n, const void* = 0)
{
if (__n > this->max_size())
std::__throw_bad_alloc();
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp))); /* SEGMENT FAULT! */
}
持续监视以下表达式的产生
(this->max_size()) = 1343857
(__n) = 4
(sizeof(_Tp)) = 3196
__n * sizeof(_Tp) = 12784
我可以说内存显然足够了，所有寄存器都很好。
但是，此段故障DID直到推入几次后才发生，因为我认为向量最初足够大，可以::operator new一直推到现在。但是，只要有必要return static_cast<_Tp *>(::operator new(__n * sizeof(_Tp)))，就会发生坏事。
尽管如此，一个事实_Tp是，它确实是一个没有DEFAULT CONSTRUCTOR的类实现，因为它具有某种引用类型的成员字段，并且默认情况下不能构造。在语义的条款static_cast<_Tp *>和operator new（原全球，而不是在我的代码覆盖），这是有可能的故障段有关？我是否应该为自己实现_Tp类型的分配器而烦恼，还是有其他解决方法？谢谢。
用
Ubuntu 12.04 x86-64, GCC 4.6.3, IDE Netbeans 7.4, std=C++98
allocate在这种情况下，该函数只是分配内存-尚未在该位置构造对象。它将全局运算符称为new，而不是您的类型的构造函数。然后它将使用new放置在结果存储块中构造您的对象。
如果您在这里遇到分段错误，则意味着内存不足，或者程序破坏了堆。损坏堆会导致未定义的行为，并且通常会在程序中从破坏它的位置崩溃得很远。可能最常见的原因是释放内存后使用内存。至少在使用free'd空间跟踪分配的系统上（例如dlmalloc，最常见的* nix分配器）。另一个常见原因是尝试注销以前由分配器处理过的缓冲区的末尾。
您不妨考虑在下运行该程序valgrind。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句