奇怪的std :: bad_alloc的

據我所知，有三個原因，一個std :: bad_alloc的可拋出：奇怪的std :: bad_alloc的

進程請求比可以提供更多的內存
地址空間太零碎，以服務爲大塊連續內存的
堆管理數據結構被破壞

我們有它運行到一個標準:: bad_alloc的代碼，但請求沒有以上原因似乎適用。數據結構是一個存儲爲std ::頂點列表的圖形，其中每個頂點再次存儲它所包含的邊的std :: list以及一些連續數據。不管每個頂點的數據部分有多大（我們可以毫無問題地總共分配高達40GB），對於小圖（< = 100'000個頂點），程序運行得很好。但是，如果頂點數量變大，我們會得到一個std :: bad_alloc異常，即使在使用「僅」8 GB內存的情況下也會拋出異常。

由於在更大塊中分配更多內存時沒有問題，所以應該排除原因1.和2.。有些章節我們會以非常容易出錯的方式來使用指針，所以我們可能會破壞堆數據結構。但是當在較小的實例上運行時，valgrind的memcheck會將我們的代碼報告爲完美無缺，因此理由似乎也不太可能（在拋出實例時，valgrind本身耗盡內存，因此我們無法直接檢查該情況）。

對於這種行爲還有什麼可能的原因還有什麼想法，或者我們可能運行什麼測試來進一步查明問題？

OS：Fedora的19
編譯系統：用gcc 4.8.2

來源

2014-01-30 gTcV

不要忘了16-20字節內存管理器通常會添加到計算中的每個分配中。 –

從技術上講，爲什麼'bad_alloc'可能被拋出只有一個原因：分配內存失敗。 – pmr

在malloc方面實現你自己的operator new，連接到一個合適的調試malloc庫，激活gdb並存儲在elbow潤滑脂上。 –

我不能在您的文章發表評論CMake的，所以我把它放在答覆。

我在使用OpenFST和Kaldi（與您的系統和gcc相同）時遇到了同樣的問題。我沒有跟蹤這個問題的確切來源，但看起來，內核3.12是這裏的問題。我使用其中一個備份內核（3.11系列之一）啓動，問題消失了。

您可以使用：

yum list --showduplicates kernel

找到可用的3.11內核。

編輯：

看來，這個錯誤是固定的內核3.12.11-201和3.13+

來源：Bugzilla

來源

2014-02-10 09:37:44 tvar0g

我們使用3.10.11內核在另一臺機器上運行我們的代碼，它工作正常！非常感謝您的提示，我們可能永遠不會想到它可能是一個內核錯誤！ – gTcV

很高興我幫了忙，也花了我一些時間去那裏;） – tvar0g

奇怪的std :: bad_alloc的

回答

相關問題