解決Win32程式記憶體超2G崩潰問題

長期以來，我們遊戲的pc版本一直飽受崩潰的困擾。其中最大的崩潰原因是在各伺服器一村的地方開啟大視距之後，就很容易崩潰。一度懷疑是記憶體問題，但在實際執行中發現應用占用的內存在1.7g左右就崩潰了。

後續經過一系列排查，崩潰的堆疊也讓人匪夷所思。例如在乙個函式內部，前幾行各數值顯示還正常，後面指標指向的記憶體就如同是被釋放過的記憶體。這不禁讓人聯想到野指標重複釋放的問題。順著這個方向，加了不少log，最終無濟於事，無法確定問題所在。

經過多次測試、除錯，終於有幾次是崩潰在glbufferdata函式呼叫中，並且有gl_out_of_memery的異常提示。終於繞了個圈回到記憶體的懷疑上來。在glbufferdata處增加了記憶體申請統計之後發現，gl申請的buffer記憶體+應用占用的記憶體之和在2g附近的時候，就會發生崩潰。這個發現立刻就讓我們把目光投向乙個地方：win32程式的記憶體使用上限限制。

一般來說32位程式的位址空間是4g，然而32位系統不可能把記憶體全都給應用程式，所以預設情況下，32位程式只能得到最多2g的記憶體。

對於 32 位作業系統，程式依然只能使用 2gb 記憶體，除非開啟了/3gb開關，開啟方法詳見：/3gb。開啟後，應用程式的使用者態將可以使用 3gb 記憶體，但核心態將只能使用 1gb 記憶體。微軟認為，是否開啟/3gb開關是計算機裝置開發商需要做的事情，開發商也需要自己測試開啟後驅動程式的效能表現和穩定性。

對於 64 位作業系統，windows 將很豪放地將 4gb 全部貢獻給這樣的程式，因為系統自己已經有更多的記憶體定址空間可以使用了，沒必要跟 32 位應用程式搶占定址空間。

在vs的postbuildevent中加入**。（專案屬性 - 生成事件 - 後期生成事件）

call "%vs110comntools%..\tools\vsvars32.bat" editbin /largeaddressaware $(targetpath)

對指令碼編譯，增加類似的操作。例如，我們採用python指令碼編譯，則在生成exe之後，執行一下**。由於一般安裝目錄在c:/programe files 這樣的目錄，中間有空格，需要用引號把路徑括起來。

def
modifyexe3g
(exepath)
: devenv = os.path.join(os.environ.get(
'vs120comntools'
), r'..\..\vc\bin')if
not os.path.exists(devenv)
:raise valueerror,
'vs2013 not exists %s'
% devenv
binpath = os.path.join(devenv,
"vcvars32.bat"
) cmd =
'\"{}\"'
.format
(os.path.abspath(binpath)
) util.report(
"modifyexe3g **********=== "
+ cmd)
os.system(cmd)
binpath = os.path.join(devenv,
"editbin"
) cmd =
'\"{}\" /largeaddressaware {}'
.format
(os.path.abspath(binpath)
, exepath)
util.report(
"modifyexe3g **********=== "
+ cmd)
os.system(cmd)

32位程式2g記憶體限制的解決方案

關於 editbin 命令的幾個說明

使 32 位程式使用大於 2gb 的記憶體

解決Win32程式記憶體超2G崩潰問題

32位程式2G記憶體限制的解決方案

解決sqlserver限制2G記憶體限制安裝

win （32位）支援4G記憶體

解決Win32程式記憶體超2G崩潰問題

32位程式2G記憶體限制的解決方案

解決sqlserver限制2G記憶體限制安裝

win （32位）支援4G記憶體

相關推薦