9

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

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

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

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

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

对于这种行为的其他原因，或者我们可能会运行哪些测试来进一步确定问题，是否有任何想法？

操作系统：Fedora 19
构建系统：cmake 和 gcc 4.8.2

4

1 回答 1

6

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

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

您可以使用：

yum list --showduplicates kernel

找到可用的 3.11 内核。

编辑：

看来，此错误已在内核 3.12.11-201 和 3.13+ 中修复

资料来源：Bugzilla

于 2014-02-10T09:37:44.243 回答