簡單使用循環動態內存會導致bad_alloc的

比方說，我有一個非常簡單的循環是這樣的：簡單使用循環動態內存會導致bad_alloc的

#include <iostream> 

int main() { 
    int i = 0; 
    while (1) 
    { 
     char* c = new char[32]; 

     std::cout << i << " " << c[0] << std::endl; 

     delete[] c; 
     i++; 
    } 
    return 0; 
}

正如你可以在循環我分配與新的運營商的一些記憶的開始看。我打印出來並刪除它。如果我運行這個代碼它可以工作，但在某一點它停止並拋出std :: bad_alloc。

我不明白爲什麼發生這種情況。它不應該耗盡內存，因爲每次刪除時都會釋放它。如果程序有足夠的內存來循環一次或兩次，它應該有足夠的內存來無限循環。它只有32個字節。

我試圖在兩臺不同的計算機上運行它，每個計算機在中斷之前執行不同次數的循環。

我做錯了什麼？

編輯：我用MinGW的G ++（GCC）4.8.1在Windows 8

來源

2014-12-28 quipe

確定這是您在此處顯示的[最小程序]（http://stackoverflow.com/help/mcve）？ –

@πάνταῥεῖ是的，我會在最後添加_int main_和_return 0_以清楚地說明。 – quipe

無法重現。請指定您的平臺，編譯器版本和編譯/鏈接選項。 – NPE

我想通了，什麼是錯誤的。我正在使用微軟應用程序驗證器的東西，我不小心留下了選擇進行測試的EXE。而且由於啓用了低資源模擬測試，因此它模擬了低內存條件。

即使窗口關閉，我也沒有意識到驗證器的工作原理。我想這可能是因爲我試圖用不同的參數編譯程序並且意外地改變了輸出文件名。更改文件名使程序起作用，所以我記得我早先指出了驗證者對原始的exe文件。

現在我覺得很傻。

來源

2014-12-28 18:21:22 quipe

你應該接受你自己的答案。 – doc

我投票結束這個問題，因爲「不再能夠重現」，因爲，情況就是如此。但你應該接受這個答案，並且從我這裏得到一個+1，並且很好地解決它。 :) –

@doc我試過了，但它說「你可以在2天內接受你自己的答案」。 – quipe

你問，如果你做錯了什麼。

從技術上講，您的代碼有undefined behaviour（UB），因爲您正在閱讀尚未初始化的c[0]。

其他，這個，你的代碼是完全沒問題的。我懷疑即使在修復UB之後，奇怪的內存行爲仍然會持續（請嘗試！）如果它仍然存在，這意味着該問題與您的代碼無關，並且可能是（相當奇怪的）屬性你的編譯器和/或運行時庫。

我測試了我的計算機上的代碼，我不能重現該問題：

Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn) 
Target: x86_64-apple-darwin13.4.0

來源

2014-12-28 18:06:53 NPE

稱爲bug的奇怪屬性:) – doc

@doc：我個人傾向於同意。然而，鑑於它可能沒有違反任何規範，這是開放的辯論（我會排除這場辯論:)）。 – NPE

簡單使用循環動態內存會導致bad_alloc的

回答

相關問題