据我所知，可以引发std :: bad_alloc的原因有三个：
我们有运行到std :: bad_alloc的代码，但是上述原因似乎都不适用。数据结构是存储为顶点的std :: list的图形，其中每个顶点再次存储作为其一部分的边的std :: list以及一定数量的连续数据。
对于小图（<= 100'000个顶点），该程序运行得非常好，而不管每个顶点的数据段有多大（我们可以毫无问题地分配总计40 GB的内存）。但是，如果顶点数量增加，即使在仅使用8 GB内存的实例上，也会引发std :: bad_alloc异常。
由于在较大的块中分配更多的内存时没有问题，因此应排除上述原因1.和2.。在某些部分中，我们以容易出错的方式处理指针，因此有可能破坏堆数据结构。但是，当在较小的实例上运行时，valgrind的memcheck报告我们的代码无缺陷，因此原因似乎也不大可能（在抛出实例时，valgrind本身会耗尽内存，因此我们无法直接检查该情况）。
是否有其他想法可能是造成这种现象的原因，或者我们可能会进行哪些测试以进一步解决问题？
操作系统：Fedora 19
构建系统：带gcc 4.8.2的cmake
我无法对您的信息发表评论，因此将其回复。
我在将OpenFST与Kaldi一起使用时遇到了相同的问题（与您的系统和gcc相同）。我没有跟踪此问题的确切来历，但似乎内核3.12就是这里的问题。我启动了其中一个备份内核（3.11系列之一），问题消失了。
您可以使用：
yum list --showduplicates kernel
查找可用的3.11内核。
编辑：
看来，此错误已在内核3.12.11-201和3.13+中修复
资料来源：Bugzilla
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句