GNU C ++库在vector分配期间卡在循环中

运行linux内核3.6.6-1，gcc 4.7.2-2，下面的程序：

1 #include <vector> 2 using namespace std; 3 int main () 4 { 5 vector<size_t> a (1 << 24); 6 return 0; 7 }

从来没有从第5行返回。

当我在gdb中运行时，发现它被卡在stl_algobase.h 743/744行：

0x000000000040101c in std::__fill_n_a<unsigned long*,unsigned long,unsigned long> (__first=0x7fffeffd8060,__n=16777216,__value=@0x7fffffffe0a8: 0) at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_algobase.h:743 740 __fill_n_a(_OutputIterator __first,_Size __n,const _Tp& __value) 741 { 742 const _Tp __tmp = __value; 743 for (__decltype(__n + 0) __niter = __n; 744 __niter > 0; --__niter,++__first) 745 *__first = __tmp; 746 return __first; 747 }

__niter只停留在值1，从不倒计数到0。

在Linux和Windows上的malloc_size替代

C编译错误：程序中出现' 4'错误; 八进制stream？

警告构build使用导出符号的内核模块

gcc开关 – 这些做什么？

如何使用u-boot为ARM处理器加载应用程序

这种行为只发生在我的系统运行了一段时间之后。 当它发生的时候，整个系统似乎都是一团糟。 也就是说，gui很快就会停止响应，但我可以ssh并做一些事情，但最终整个系统变得无法使用，我重新启动。

重新启动后，上述程序的行为如预期。

显然，问题不在我的程序中。 这只是一个更大的问题的症状。

我的问题是：接下来我该做什么？

我已经检查了所有的错误日志，什么都没发现。 我没有得到硬件exception或类似的东西，所以很难准确地说出我的系统何时进入这个状态。

我出来的想法，所以任何帮助将非常感激。

编辑：

我将我的编译器选项更改为-g -Wall并获得相同的结果。

这是__fill_n_a的反汇编（带有新的选项）：

1 0x00000000004010bd <+0>: push %rbp 2 0x00000000004010be <+1>: mov %rsp,%rbp 3 0x00000000004010c1 <+4>: mov %rdi,-0x18(%rbp) 4 0x00000000004010c5 <+8>: mov %rsi,-0x20(%rbp) 5 0x00000000004010c9 <+12>: mov %rdx,-0x28(%rbp) 6 0x00000000004010cd <+16>: mov -0x28(%rbp),%rax 7 0x00000000004010d1 <+20>: mov (%rax),%rax 8 0x00000000004010d4 <+23>: mov %rax,-0x10(%rbp) 9 0x00000000004010d8 <+27>: mov -0x20(%rbp),%rax 10 0x00000000004010dc <+31>: mov %rax,-0x8(%rbp) 11 0x00000000004010e0 <+35>: jmp 0x4010f7 <std::__fill_n_a<unsigned long*,unsigned long>(unsigned long*,unsigned long const&)+58> 12 0x00000000004010e2 <+37>: mov -0x18(%rbp),%rax 13 0x00000000004010e6 <+41>: mov -0x10(%rbp),%rdx 14 0x00000000004010ea <+45>: mov %rdx,(%rax) 15 0x00000000004010ed <+48>: subq $0x1,-0x8(%rbp) 16 0x00000000004010f2 <+53>: addq $0x8,-0x18(%rbp) 17 0x00000000004010f7 <+58>: cmpq $0x0,-0x8(%rbp) 18 0x00000000004010fc <+63>: setne %al 19 0x00000000004010ff <+66>: test %al,%al 20 0x0000000000401101 <+68>: jne 0x4010e2 <std::__fill_n_a<unsigned long*,unsigned long const&)+37> 21 0x0000000000401103 <+70>: mov -0x18(%rbp),%rax 22 0x0000000000401107 <+74>: pop %rbp 23 0x0000000000401108 <+75>: retq

我也运行了我的系统的内存诊断工具，没有错误，正如DL所build议的，运行memtest86没有任何错误。

编辑：

我已经通过在不同的机器上运行相同的代码，证实这不是硬件问题。 另一台机器安装了相同的内核和编译器软件，并以相同的方式失败。

我怀疑ImageMagick。 这似乎只有在我运行脚本，使大量的ImageMagick转换调用后才会发生。 我以前有ImageMagick的问题，必须设置shellvariablesMAGICK_THREAD_LIMIT = 1。

为什么我的代码会在启动函数结束时崩溃？

如何使用MinGW在命令行上编译C程序？

使用共享库的问题

使用dlsym（）在静态链接库中查找variables

英特尔galileo – greenlet.h：8：20：致命错误：Python.h：没有这样的文件或目录

你描述的整体症状听起来像是内存不足。 如果系统内存使用率不高，这可能是由于某些内存问题，正如评论者所指出的那样。

你说：

__niter只停留在值1，从不倒计数到0。

但是这并不合理，__niter应该以16777216开头，然后倒数为0.如果你想随机分成这个程序，几乎肯定会在这个循环中，但__niter的值几乎肯定不会是1然而，如果你通过循环，它似乎只是循环。 我高度怀疑gcc 4.7（实际上，它是gcc 4.0以后的一个问题）的调试信息，在gdb经常似乎打印出本地变量的错误值，但是如果你检查代码，并看看和内存/寄存器直接可以看到正确的值。 如果这就是发生了什么事情，你的问题可能与这个程序无关。 它的系统不稳定（可能是由于硬件问题），表现为挂起的东西，比如这个程序。 鉴于这个程序做了什么，可能会发生挂起时，它接触到一个以前未触摸的页面（获取页面错误），内核尝试分配一个页面。 这表明存在内存问题，但您注意到您已经运行了内存诊断程序。 另外请确保你没有任何东西超频或以其他方式超出规格。