MFC内存泄露

1、泄露代码示例

void X::SetApplicationBtn()
{
    CMFCRibbonApplicationButton* pBtn = GetApplicationButton();
    // 获取 Ribbon Bar 指针
        // 创建自定义按钮
    CCustomRibbonAppButton* pCustomButton = new CCustomRibbonAppButton();
    pCustomButton->SetImage(IDB_BITMAP_Jdp26);
    // 替换默认的 Application Button
    this->SetApplicationButton(pCustomButton, CSize(45, 45));
}

2、CRT 

3、使用CRT调试功能来检测内存泄漏

笔记小结

1.1 使用方式

// 使用调试堆函数：

#define _CRTDBG_MAP_ALLOC
#include<stdlib.h>
#include<crtdbg.h>

// 检测内存泄漏的地方添加下面这条语句来输出内存泄漏信息
_CrtDumpMemoryLeaks();

1.2 相关介绍

// 分配泄漏内存的文件名，以及文件名后括号中的数字表示发生泄漏的代码行号
#define _CRTDBG_MAP_ALLOC

1.2-1 内存泄露提示（和上述内存泄露代码无关）

Detected memory leaks!
Dumping objects ->
D:\a\_work\1\s\src\vctools\crt\github\stl\src\locale0.cpp(34) : {91690} crt block at 0x0000020FDD50EF20, subtype 0, 16 bytes long.
 Data: <          P     > 00 00 00 00 00 00 00 00 90 F2 50 DD 0F 02 00 00

1.3 内存块类型

normal（普通）、client（客户端）、 CRT（运行时）

normal block（普通块）：这是由你的程序分配的内存。
client block（客户块）：这是一种特殊类型的内存块，专门用于 MFC 程序中需要析构函数的对象。MFC new 操作符视具体情况既可以为所创建的对象建立普通块，也可以为之建立客户块。
CRT block（CRT 块）：是由 C RunTime Library 供自己使用而分配的内存块。由 CRT 库自己来管理这些内存的分配与释放，我们一般不会在内存泄漏报告中发现 CRT 内存泄漏，除非程序发生了严重的错误（例如 CRT 库崩溃）。

1.4  输出泄露

// 无论程序在什么地方退出都会自动调用 _CrtDumpMemoryLeak
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

1.5 内存泄露信息 输出定向到别的地方

//
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );

4、设置断点

内存分配序号：件名和行号之后的花括弧里的那个数字。

        CRT 库对程序运行期间分配的所有内存块进行计数，包括由 CRT 库自己分配的内存和其它库（如 MFC）分配的内存。因此，分配序号为 N 的对象即为程序中分配的第 N 个对象，但不一定是代码分配的第 N 个对象。

        方法是在程序起始附近设置一个位置断点。当程序在该点中断时，可以从 QuickWatch（快速监视）对话框或 Watch（监视）窗口设置一个内存分配断点。

// Watch 窗口中，在 Name 栏键入下面的表达式：

_crtBreakAlloc

 Watch 窗口中，在 Name 栏键入下面的表达式：

　如果要使用 CRT 库的多线程 DLL 版本（/MD 选项），那么必须包含上下文操作符，像这样：
 

{,,msvcrtd.dll}_crtBreakAlloc

　　现在按下回车键，调试器将计算该值并把结果放入 Value 栏。如果没有在内存分配点设置任何断点，该值将为 –1。

5、MFC多文档使用示例

直接使用_CrtSetDbgFlag | Microsoft Learn

BOOL X::InitInstance()
{
    // 启用自动内存泄漏检测（调试模式）
#ifdef _DEBUG
    _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
#endif
……
}

特别解释：

尽量避免不必要得使用：_CrtDumpMemoryLeaks 

6、deepseek的

关于 `_CrtDumpMemoryLeaks` 在 MFC 中的使用位置和避免误报的问题，你的理解非常正确。`ExitInstance` 和析构函数确实是常见的误报点，核心原因就在于 检测时机过早。下面详细解释原因并提供解决方案：

 1. 为什么在 `ExitInstance` 或析构函数中使用 `_CrtDumpMemoryLeaks` 会产生误报？

MFC 框架/静态对象清理滞后： `ExitInstance` 是 `CWinApp` 的成员函数，它在应用程序的主消息循环结束后、主窗口已销毁时调用。析构函数（尤其是 `CWinApp` 的析构函数）也发生在这个阶段。关键点在于：
    MFC 内部对象： MFC 框架自身可能还有一些内部对象（如文档模板、线程局部存储、内部缓存等）需要在 `ExitInstance` 之后或 `CWinApp` 析构之后才被完全清理。
    全局/静态对象： 你的代码或第三方库中定义的全局对象 (`CMyGlobalObject globalObj;`) 或静态对象 (`static CMyStaticObject staticObj;`) 的析构函数，它们的执行顺序是由编译器决定的，并且可能发生在 `CWinApp` 析构之后。
检测时机过早： 在 `ExitInstance` 或 `CWinApp` 析构函数中调用 `_CrtDumpMemoryLeaks` 时，上述那些滞后清理的 MFC 内部对象和全局/静态对象还没有被销毁。这些对象所占用的内存，在 `_CrtDumpMemoryLeaks` 看来就是“尚未释放”的内存，从而被错误地报告为内存泄漏。

总结： `ExitInstance` 和析构函数发生在应用程序生命周期的“中间”阶段，此时并非所有内存使用者（尤其是全局/静态对象）都已结束生命并释放内存。在此处检测，必然会将那些稍后才释放的对象误报为泄漏。

 2. 如何正确使用 `_CrtDumpMemoryLeaks` 避免误报？

解决方案的核心在于：确保检测发生在所有用户代码（包括全局/静态对象析构）和 MFC 框架清理工作都已完成之后。 以下是几种推荐且有效的方法：

方法 1: 利用 `_CrtSetDbgFlag` 设置自动报告 (最推荐)

原理： 在 `InitInstance` 的最开始设置调试标志，告诉 C 运行时库在程序完全退出时（即所有全局/静态对象析构完成后）自动调用 `_CrtDumpMemoryLeaks`。
位置： `CMyApp::InitInstance()` 的开头。
代码：

    ```cpp
    BOOL CMyApp::InitInstance()
    {
        // 在 InitInstance 最开始设置内存泄漏检测标志 (仅 Debug 模式)
    #ifdef _DEBUG
        _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
    #endif

        // ... 其他初始化代码 (注册文档模板、创建主窗口等) ...
        return TRUE;
    }
    ```

优点:
    时机最准确： 检测发生在程序生命周期的最后（所有全局/静态对象析构后），最大程度减少误报。
    无需手动调用： 自动执行，方便可靠。
    标准做法： 这是 VC++ 调试内存泄漏的官方推荐方式。
缺点： 输出在调试器输出窗口（如 VS 的 Output 窗口），可能不如写入文件直观（但通常足够）。

方法 2: 在 `main`/`WinMain` 函数返回前调用 (适用于明确入口点)

原理： 如果你的应用程序入口点是标准的 `WinMain` 或 `main` (MFC 通常隐藏了 `WinMain`)，可以在入口函数的 `return` 语句之前调用 `_CrtDumpMemoryLeaks`。
位置： `WinMain` 或 `main` 函数结束前 (`return` 之前)。
代码 (示例 `WinMain`, 通常由 MFC 提供)：
    ```cpp
    #include <afxwin.h> // 确保包含 MFC 头文件
    #include <crtdbg.h>

    int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
    {
        // ... MFC 初始化 (通常隐含在 AfxWinMain 中) ...

        CWinApp* pApp = AfxGetApp();
        if (pApp != nullptr)
        {
            pApp->InitApplication();
            pApp->InitInstance();
            pApp->Run();
            pApp->ExitInstance(); // MFC 框架调用
        }

        // 在 WinMain 返回前，所有全局/静态对象应已析构
    #ifdef _DEBUG
        _CrtDumpMemoryLeaks(); // 在此处检测
    #endif

        return 0;
    }
    ```
    实际应用中，你通常需要修改 MFC 提供的 `WinMain` 实现（在 `appmodul.cpp` 或类似文件中）。
优点： 时机也相对较晚（在 `ExitInstance` 之后，所有全局/静态对象析构后，程序真正结束前）。
缺点：
    MFC 应用程序的入口点通常被框架封装 (`AfxWinMain`)，直接修改它需要找到对应的源文件（如 `appmodul.cpp`）并可能影响项目结构。
    不如方法 1 方便通用。

方法 3: 使用静态对象析构函数 (高级技巧)

原理： 定义一个全局的静态对象。C++ 保证全局静态对象在 `main`/`WinMain` 结束后、程序完全退出前析构。在这个静态对象的析构函数中调用 `_CrtDumpMemoryLeaks`。
位置： 在一个全局静态对象的析构函数中。
代码：
    ```cpp
    // 在你的某个 .cpp 文件中
    class LeakDetectorFinalizer {
    public:
        ~LeakDetectorFinalizer() {
    #ifdef _DEBUG
            _CrtDumpMemoryLeaks(); // 在静态对象析构时检测
    #endif
        }
    };

    // 定义一个全局静态实例
    static LeakDetectorFinalizer s_finalLeakChecker;
    ```
优点： 理论上时机也很晚（在大多数其他全局/静态对象析构之后）。
缺点：
    析构顺序不确定性： C++ 标准只规定了同一编译单元内静态对象析构的逆初始化顺序，不同编译单元间的析构顺序是未定义的。如果存在其他全局静态对象依赖后释放的资源，且它们在 `s_finalLeakChecker` 之后析构，那么这些对象仍会被误报为泄漏。这种方法不如方法 1 可靠。
    略显晦涩。

 总结与最佳实践

1.  绝对避免在 `ExitInstance` 和 `CWinApp` 析构函数中调用 `_CrtDumpMemoryLeaks`： 这是误报的主要根源。
2.  首选方法： 在 `InitInstance` 开头使用 `_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);`。这是 VC++/MFC 调试内存泄漏的标准、最可靠、误报最少的方法。它确保了检测发生在程序生命周期的最后。
3.  替代方法 (谨慎使用)：
    修改 `WinMain`/`main` 在 `return` 前调用：时机正确，但修改 MFC 入口点文件稍显麻烦。
    静态对象析构函数调用：理论上可行，但受限于静态对象析构顺序的不确定性，不推荐作为首选。
4.  仅限 Debug 模式： 务必使用 `#ifdef _DEBUG` 和 `#endif` 将内存泄漏检测代码包裹起来，确保它们只在调试版本中编译和执行。在 Release 版本中检测不仅无效（因优化可能导致信息不准），还会增加不必要的开销。
5.  理解输出： 即使使用最佳方法，有时也会看到一些来自 MFC 内部或第三方库的“报告”。学习识别这些常见的“伪泄漏”（通常分配号固定）或使用 `_CrtSetBreakAlloc` 配合分配号来精确定位真正的泄漏点。`_CrtMemCheckpoint` 和 `_CrtMemDifference` 可用于在程序关键点进行更精细的内存状态快照比较。

核心要点：延迟检测！ 让 `_CrtDumpMemoryLeaks` 在程序真正结束、所有资源（尤其是全局/静态对象）都释放完毕之后再执行，是解决误报问题的关键。`_CrtSetDbgFlag` 方法正是利用了 C 运行时库自身在退出时的最后清理点来保证这一点。

7、断点示例（实操）

错误太多就分模块屏蔽

错误提示

Detected memory leaks!
Dumping objects ->
{9986} normal block at 0x00000248AB882D40, 1 bytes long.
 Data: < > CD 
{9978} normal block at 0x00000248AB88F300, 16 bytes long.
 Data: <    H           > E0 D3 88 AB 48 02 00 00 00 00 00 00 00 00 00 00 

代码断点

BOOL X::InitInstance()
{
    // 启用自动内存泄漏检测（调试模式）
#ifdef _DEBUG
    _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
    _CrtSetBreakAlloc(9986);
#endif
……
}

代码定位问题出处

（自定定义的单例把释放的new屏蔽掉了导致的）

8、内存泄露实操方案（Hook）

8.1、在自定的.cpp文件加上

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

 8.2 使用hook

#ifdef _NewLeak
int __cdecl AllocHook(int allocType, void* userData, size_t size,
    int blockType, long requestNumber, const unsigned char* filename, int lineNumber) {
    char buffer[512];
    if (requestNumber > 0) // 屏蔽掉分配的
    {
        sprintf_s(buffer, sizeof(buffer),
            "分配序号: %ld, 大小: %zu, 文件: %s, 行号: %d\n",
            requestNumber, size, filename ? (const char*)filename : "未知", lineNumber);
        OutputDebugStringA(buffer);
    }
    return TRUE;
}
#endif

BOOL X::InitInstance()
{
    // 启用自动内存泄漏检测（调试模式）
#ifdef _NewLeak
    _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
    _CrtSetAllocHook(AllocHook);
#endif
……
}

8.3 可以在自己new的代码打个断点执行完毕即可看到  输出框 职中的显示
9、内存泄露实操
分段屏蔽，逐步缩小内存泄露范围

比如经过屏蔽测试

 m_capture.open(0); 会导致内存泄露