最近寫的MFC專案快結束了，正在進行整存泄露檢測。發現一處很特別的地方發生了記憶體泄漏，泄露提示如下：
Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp(4500) : {563} client block at 0x0184A3C8, subtype c0, 56 bytes long.
a CObject object at $0184A3C8, 56 bytes long
{548} normal block at 0x01849438, 40 bytes long.
Data: <8 8 8 > 38 94 84 01 38 94 84 01 38 94 84 01 CD CD CD CD
{547} normal block at 0x018492B8, 8 bytes long.
Data: < I > D4 FD 49 00 00 00 00 00
d:\vs2010\ect1\ect1\ect1.cpp(59) : {544} client block at 0x01849210, subtype c0, 12 bytes long.
a CObject object at $01849210, 12 bytes long
{543} client block at 0x01849330, subtype c0, 204 bytes long.
a CObject object at $01849330, 204 bytes long
使用_CrtSetBreakAlloc(563); 定位，使用shitf+F11，想上回溯到了一句系統自動生成的陳述句：
CMenu* pSysMenu = GetSystemMenu(FALSE);
說先申明：本程式并沒有對主頁面添加選單。
還有一種記憶體泄漏比較嚴重的是這樣提示的：、
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {443} normal block at 0x01846478, 22 bytes long.
Data: <T vx > 54 CD 76 78 05 00 00 00 05 00 00 00 01 00 00 00
這種提示多大好幾十處，我覺得是CString變數使用不規范造成的，但是一時也想不到原因。
大家幫忙分析下，我這兩種記憶體泄漏到底出錯在哪里了。
uj5u.com熱心網友回復：
查哪里使用了 newuj5u.com熱心網友回復：
檢查 new 出來的東西，一定要 delete.d:\vs2010\ect1\ect1\ect1.cpp(59) 是什么？
uj5u.com熱心網友回復：
請看這篇文章http://www.cppblog.com/oyrp/articles/102251.html或者注釋一部分代碼進行檢測
uj5u.com熱心網友回復：
CString::GetBufferLPTSTR GetBuffer( int nMinBufLength );
throw( CMemoryException );
Return Value
An LPTSTR pointer to the object’s (null-terminated) character buffer.
Parameters
nMinBufLength
The minimum size of the character buffer in characters. This value does not include space for a null terminator.
Remarks
Returns a pointer to the internal character buffer for the CString object. The returned LPTSTR is not const and thus allows direct modification of CString contents.
If you use the pointer returned by GetBuffer to change the string contents, you must call ReleaseBuffer before using any other CString member functions.
The address returned by GetBuffer may not be valid after the call to ReleaseBuffer since additional CString operations may cause the CString buffer to be reallocated. The buffer will not be reallocated if you do not change the length of the CString.
The buffer memory will be freed automatically when the CString object is destroyed.
Note that if you keep track of the string length yourself, you should not append the terminating null character. You must, however, specify the final string length when you release the buffer with ReleaseBuffer. If you do append a terminating null character, you should pass –1 for the length to ReleaseBuffer and ReleaseBuffer will perform a strlen on the buffer to determine its length.
Example
The following example demonstrates the use of CString::GetBuffer.
// example for CString::GetBuffer
CString s( "abcd" );
#ifdef _DEBUG
afxDump << "CString s " << s << "\n";
#endif
LPTSTR p = s.GetBuffer( 10 );
strcpy( p, "Hello" ); // directly access CString buffer
s.ReleaseBuffer( );
#ifdef _DEBUG
afxDump << "CString s " << s << "\n";
#endif
CString Overview | Class Members | Hierarchy Chart
See Also CString::GetBufferSetLength, CString::ReleaseBuffer
uj5u.com熱心網友回復：
GetSystemMenuThe GetSystemMenu function allows the application to access the window menu (also known as the system menu or the control menu) for copying and modifying.
HMENU GetSystemMenu(
HWND hWnd, // handle to window to own window menu
BOOL bRevert // reset flag
);
Parameters
hWnd
Handle to the window that will own a copy of the window menu.
bRevert
Specifies the action to be taken. If this parameter is FALSE, GetSystemMenu returns the handle to the copy of the window menu currently in use. The copy is initially identical to the window menu, but it can be modified.
If this parameter is TRUE, GetSystemMenu resets the window menu back to the default state. The previous window menu, if any, is destroyed.
Return Values
If the bRevert parameter is FALSE, the return value is the handle to a copy of the window menu. If the bRevert parameter is TRUE, the return value is NULL.
Remarks
Any window that does not use the GetSystemMenu function to make its own copy of the window menu receives the standard window menu.
The window menu initially contains items with various identifier values, such as SC_CLOSE, SC_MOVE, and SC_SIZE.
Menu items on the window menu send WM_SYSCOMMAND messages.
All predefined window menu items have identifier numbers greater than 0xF000. If an application adds commands to the window menu, it should use identifier numbers less than 0xF000.
The system automatically grays items on the standard window menu, depending on the situation. The application can perform its own checking or graying by responding to the WM_INITMENU message that is sent before any menu is displayed.
Windows CE: Windows CE does not support a system menu, but GetSystemMenu is implemented as a macro to maintain compatibility with existing code. You can use the menu handle returned by this macro to disable the close box the same way you would in a Windows desktop platform. There is no other use for the return value in Windows CE. The brevert parameter is ignored. Use the following code to disable the Close button:
EnableMenuItem (GetSystemMenu(hwnd, FALSE), SC_CLOSE,MF_BYCOMMAND | MF_GRAYED);
QuickInfo
Windows NT: Requires version 3.1 or later.
Windows: Requires Windows 95 or later.
Windows CE: Requires version 1.0 or later.
Header: Declared in winuser.h.
Import Library: Use user32.lib.
See Also
Menus Overview, Menu Functions, GetMenu, WM_INITMENU, WM_SYSCOMMAND
uj5u.com熱心網友回復：
new的都delete,都查過了。
uj5u.com熱心網友回復：
CShellManager *pShellManager = new CShellManager;
系統自帶的。
uj5u.com熱心網友回復：
我并沒有使用GetBuffer這個函式。
uj5u.com熱心網友回復：
在 DestroyWindow 中if (pShellManager != NULL)
{
delete pShellManager;
}
uj5u.com熱心網友回復：
不對，這段代碼在class CECTApp : public CWinApp里面。CWinApp并不存在DestroyWindow 這個函式，而且有問題的代碼是系統自動生成的，難道系統自己生成的代碼也有問題;代碼如下：
BOOL CECT1App::InitInstance()
{
// 如果一個運行在 Windows XP 上的應用程式清單指定要
// 使用 ComCtl32.dll 版本 6 或更高版本來啟用可視化方式，
//則需要 InitCommonControlsEx()。否則，將無法創建視窗。
INITCOMMONCONTROLSEX InitCtrls;
InitCtrls.dwSize = sizeof(InitCtrls);
// 將它設定為包括所有要在應用程式中使用的
// 公共控制元件類。
InitCtrls.dwICC = ICC_WIN95_CLASSES;
InitCommonControlsEx(&InitCtrls);
CWinApp::InitInstance();
AfxEnableControlContainer();
// 創建 shell 管理器，以防對話框包含
// 任何 shell 樹視圖控制元件或 shell 串列視圖控制元件。
CShellManager *pShellManager = new CShellManager;
// 標準初始化
// 如果未使用這些功能并希望減小
// 最終可執行檔案的大小，則應移除下列
// 不需要的特定初始化例程
// 更改用于存盤設定的注冊表項
// TODO: 應適當修改該字串，
// 例如修改為公司或組織名
SetRegistryKey(_T("應用程式向導生成的本地應用程式"));
CECT1Dlg dlg;
m_pMainWnd = &dlg;
INT_PTR nResponse = dlg.DoModal();
if (nResponse == IDOK)
{
// TODO: 在此放置處理何時用
// “確定”來關閉對話框的代碼
}
else if (nResponse == IDCANCEL)
{
// TODO: 在此放置處理何時用
// “取消”來關閉對話框的代碼
}
// 洗掉上面創建的 shell 管理器。
if (pShellManager != NULL)
{
delete pShellManager;
}
// 由于對話框已關閉，所以將回傳 FALSE 以便退出應用程式，
// 而不是啟動應用程式的訊息泵。
return FALSE;
}
uj5u.com熱心網友回復：
能不能給點有用的建議，說明檔案我也能找到。
uj5u.com熱心網友回復：
int CxxxxApp::ExitInstance()uj5u.com熱心網友回復：
我查了下，這段代碼我用不上，我就直接給刪了。
uj5u.com熱心網友回復：
int CxxxxApp::ExitInstance()
{
if (pShellManager != NULL)
{
delete pShellManager;
}
}
uj5u.com熱心網友回復：
我也遇到了一模一樣的問題. 感覺 CString 只要用了,立馬就會有記憶體泄漏,根本不知道是什么原因,現在都不敢用 CString 了.樓主是哪里人?
uj5u.com熱心網友回復：
pShellManager 是Instance函式的區域變數，不是全域的。這么寫不合適，即使是全域的，我也打算把這個刪了，我用不到。我記得這個好像是VS2005開始加進來的，以前都沒有。
uj5u.com熱心網友回復：
.我用了好多。。。。。。你這么說，我以后編程也不敢用了。是不是string比較安全？
uj5u.com熱心網友回復：
他在瞎說，CString跟記憶體泄漏沒有半毛錢關系，功夫不到家怪編譯器
uj5u.com熱心網友回復：
好吧，我一直沒找到是什么原因導致了CString記憶體泄露。
uj5u.com熱心網友回復：
我知道不是CString引起的, 但現象跟樓主的一樣, 肯定是某一個地方有漏洞,但究竟是哪里出錯了,以我目前的三腳貓功夫, 是真的不知道, 也查不出來.
uj5u.com熱心網友回復：
"不是CString引起的" 你的 vc 版本可能有問題uj5u.com熱心網友回復：
new出來的東西初始化了嗎？uj5u.com熱心網友回復：
CString使用不當確實是會導致記憶體泄漏問題~uj5u.com熱心網友回復：
3VS2010，你是說安裝程序有問題？
uj5u.com熱心網友回復：
3初始化了，而且都delete了。
uj5u.com熱心網友回復：
我覺得是CString的問題，但是不清楚是什么原因引起的。
uj5u.com熱心網友回復：
對這種問題一直沒辦法，進來學習下uj5u.com熱心網友回復：
還沒有解決嗎？排除你的 CString 外， 檢查是否 關閉程式后，子執行緒未正確退出引出？ 這樣的記憶體泄露也會反饋到 strcore.cpp 上。
另外，根據你的第一個 wincore.cpp 報告泄漏，也懷疑你的程式中有 非模態對話框沒有正常的退出。 檢查一下邏輯關系。
==
這樣的問題比較復雜，在有限的條件 下只能這樣提供思路。
uj5u.com熱心網友回復：
還沒解決呢。
uj5u.com熱心網友回復：
有用，多謝提醒，我用OpenGL在對話框上開了個視窗。但是注釋掉那段代碼后還是會出現記憶體泄漏。
uj5u.com熱心網友回復：
進來看這個貼，居然我也遇到相同的問題了。是什么原因呢？
uj5u.com熱心網友回復：
快速找到記憶體泄漏單確定了記憶體泄漏發生在哪一行，有時候并不足夠。特別是同一個new對應有多處釋放的情形。在實際的工程中，以下兩種情況很典型：
創建物件的地方是一個類工廠（ClassFactory）模式。很多甚至全部類實體由同一個new創建。對于此，定位到了new出物件的所在行基本沒有多大幫助。
COM物件。我們知道COM物件采用Reference Count維護生命周期。也就是說，物件new的地方只有一個，但是Release的地方很多，你要一個個排除。
那么，有什么好辦法，可以迅速定位記憶體泄漏？
答：有。
在記憶體泄漏情況復雜的時候，你可以用以下方法定位記憶體泄漏。這是我個人認為通用的記憶體泄漏追蹤方法中最有效的手段。
我們再回頭看看crtdbg生成的記憶體泄漏報告：
Detected memory leaks!
Dumping objects ->
c:\work\test.cpp(186) : {52} normal block at 0x003C4410, 40 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
除了產生該記憶體泄漏的記憶體分配陳述句所在的檔案名、行號為，我們注意到有一個比較陌生的資訊：{52}。這個整數值代表了什么意思呢？
其實，它代表了第幾次記憶體分配操作。象這個例子，{52}代表了第52次記憶體分配操作發生了泄漏。你可能要說，我只new過一次，怎么會是第52次？這很容易理解，其他的記憶體申請操作在C的初始化程序呼叫的唄。:)
有沒有可能，我們讓程式運行到第52次記憶體分配操作的時候，自動停下來，進入除錯狀態？所幸，crtdbg確實提供了這樣的函式：即 long _CrtSetBreakAlloc(long nAllocID)。我們加上它：
inline void EnableMemLeakCheck()
{
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
}
#ifdef _DEBUG
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif
void main()
{
EnableMemLeakCheck();
_CrtSetBreakAlloc(52);
int* leak = new int[10];
}
你發現，程式運行到 int* leak = new int[10]; 一句時，自動停下來進入除錯狀態。細細體會一下，你可以發現，這種方式你獲得的資訊遠比在程式退出時獲得檔案名及行號有價值得多。因為報告泄漏檔案名及行號，你獲得的只是靜態的資訊，然而_CrtSetBreakAlloc則是把整個現場恢復，你可以通過對函式呼叫堆疊分析（我發現很多人不習慣看函式呼叫堆疊，如果你屬于這種情況，我強烈推薦你去補上這一課，因為它太重要了）以及其他在線除錯技巧，來分析產生記憶體泄漏的原因。通常情況下，這種分析方法可以在5分鐘內找到肇事者。
當然，_CrtSetBreakAlloc要求你的程式執行程序是可還原的（多次執行程序的記憶體分配順序不會發生變化）。這個假設在多數情況下成立。不過，在多執行緒的情況下，這一點有時難以保證。
uj5u.com熱心網友回復：
記憶體泄漏報告，很多場合是參考依賴庫造成的假象。可以在連接器-依賴項-中延遲加載的dll中設定依賴的dll，這樣基本上不會虛報uj5u.com熱心網友回復：
我個人覺得：應該是你的對話框沒有正確退出（或者對話框退出時沒有釋放對話框所擁有的資源）才導致的你的這個記憶體泄漏。把排查重點放到你的CECT1Dlg類中，不要在App中做無用功了
uj5u.com熱心網友回復：
學習了，謝謝uj5u.com熱心網友回復：
我最近也發現了，自己new的東西都delete了，但是就是報記憶體泄漏，而且都是系統自己生成的代碼造成的。不知道咋回事uj5u.com熱心網友回復：
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp(4500) : {563} client block at 0x0184A3C8, subtype c0, 56 bytes long.
a CObject object at $0184A3C8, 56 bytes long
{548} normal block at 0x01849438, 40 bytes long.
Data: <8 8 8 > 38 94 84 01 38 94 84 01 38 94 84 01 CD CD CD CD
{547} normal block at 0x018492B8, 8 bytes long.
Data: < I > D4 FD 49 00 00 00 00 00
其實是下面這個地方記憶體泄漏引起上面的：f:\dd\......
d:\vs2010\ect1\ect1\ect1.cpp(59) : {544} client block at 0x01849210, subtype c0, 12 bytes long.
不要說“自己的代碼絕對沒問題“，”絕對都釋放了之類的話“，必定是你的代碼有問題，再好好檢查下吧
uj5u.com熱心網友回復：
泄露的資訊里不寫了具體哪一行有問題了嗎，貼出對應的代碼來看看uj5u.com熱心網友回復：
導致記憶體泄漏的原因有好多呢。。。不光new、delete，還有gdi泄漏啊什么的，我覺得你可以先運行程式然后查看任務管理器里的記憶體變化情況，或者你百度一個SystemInfo，這個東西可以幫你看程式運行時的記憶體變化情況，如果它一直升高，那肯定有問題。然后你的程式中有沒有用到第三方，你看看你的debug下面有沒有一些可疑的dll，如果有些可以刪掉的話而不影響程式運行的話，那就刪掉然后再看記憶體變化情況。
最后你這個是VLD監測嗎，這個東西還是不敢恭維啊。。。。
uj5u.com熱心網友回復：
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156)這種CString的泄露, 99%都是在執行緒中使用了CString物件, 然后容易報這個記憶體泄露.
估計是你的程式沒有正常結束, 也就是說結束是有些地方崩潰了,
uj5u.com熱心網友回復：
代碼發到[email protected]我給你看看，不要懷疑mfc，記憶體泄漏問題的定位有那么復雜嘛
uj5u.com熱心網友回復：
11點以前，過時不候！uj5u.com熱心網友回復：
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);uj5u.com熱心網友回復：
使用CString::GetBuffer后要記得ReleaseBufferuj5u.com熱心網友回復：
長了姿勢。。。從來不記得releaseBuffer
uj5u.com熱心網友回復：
虎頭蛇尾是俗人的習慣，有始有終是君子的操守。
uj5u.com熱心網友回復：
http://www.cnblogs.com/skynet/archive/2011/02/20/1959162.html 你可以嘗試一下。我感覺不是CString出問題，而是你用的有問題。你要仔細查看代碼，確保new的一定被delete掉了，還有一些需要呼叫release的轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/102570.html
標籤：界面