奇怪的std :: bad_alloc

Question

据我所知，有三个原因可以抛出std :: bad_alloc：

1. 该进程请求的内存多于可以提供的内存
2. 地址空间过于分散，无法满足大块连续内存的请求
3. 堆管理数据结构已损坏

我们有运行到std :: bad_alloc的代码，但上述原因似乎都不适用。 数据结构是一个存储为std :: verts列表的图形，其中每个顶点再次存储std :: list的边缘列表，以及一些连续数据。

对于小图形（<= 100'000个顶点），程序运行完全正常，无论每个顶点的数据部分有多大（我们可以毫无问题地分配最多40 GB）。 但是，如果顶点的数量变大，即使在使用“仅”8 GB内存的实例上，我们也会抛出std :: bad_alloc异常。

由于在较大的块中分配更多内存时没有问题，因此应排除上述原因1.和2. 有一些部分我们以极易出错的方式使用指针，因此我们可能会破坏堆数据结构。 但是当在较小的实例上运行时，valgrind的memcheck会将我们的代码报告为完美无缺，因此理由似乎也不太可能（在抛出实例时，valgrind本身会耗尽内存，所以我们无法直接检查这种情况）。

是否有任何关于这种行为可能是什么原因的想法，或者我们可能会进行哪些测试以进一步确定问题？

操作系统：Fedora 19
构建系统：使用gcc 4.8.2进行cmake

Answer 1

我无法评论你的帖子，所以我会回复。

我在使用OpenFST和Kaldi时遇到了同样的问题（与你的系统和gcc相同）。 我没有跟踪这个问题的确切起源，但似乎内核3.12就是问题所在。 我用其中一个备份内核（3.11系列之一）启动，问题就消失了。

您可以使用：

yum list --showduplicates kernel

找到可用的3.11内核。

编辑：

似乎这个错误在内核3.12.11-201和3.13+中得到修复

资料来源： Bugzilla