none
坑爹的VS 2008内存泄露报告 RRS feed

  • 问题

  •    使用VS 2008+sp1 (win xp环境下)编一个含有多个dll工程和一个exe工程的项目,其中有一个dll动态链接了boost_filesystem-vc90-mt-gd-1_42.dll,程序退出时提示:

        Dumping objects ->
    {119} normal block at 0x015A63A8, 80 bytes long.
     Data: <ABCDEFGHIJKLMNOP> 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50
    {118} normal block at 0x015A6338, 48 bytes long.
     Data: < > 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
    Object dump complete.

         开始还不知道哪个模块出现了内存泄露,因为根本没有提示在哪个源代码文件出现内存泄露。用_CrtSetBreakAlloc 函数定位也没找到。最后通过设置数据断点确认是在boost_filesystem-vc90-mt-gd-1_42.dll出现内存泄露。然后想解决这个问题。到
    网上搜索资料,终于搜到了有人和我遇到一样的问题的一篇帖子:[url=http://topic.csdn.net/t/20061212/11/5224278.html]boost会有内存泄漏?[/url]

         该帖子说:我写了一个MFC程序调用我自己写的win32   DLL   (非MFC   DLL),在DLL中调用了boost的filesystem库,在主程序退出调试后,output窗口中报告出现了内存泄漏:

    Detected   memory   leaks!
    Dumping   objects   ->
    {119}   normal   block   at   0x00396060,   80   bytes   long.
      Data:   <ABCDEFGHIJKLMNOP>   41   42   43   44   45   46   47   48   49   4A   4B   4C   4D   4E   4F   50  
    {118}   normal   block   at   0x00395FF0,   48   bytes   long.
      Data:   <                                 >   01   02   03   04   05   06   07   08   09   0A   0B   0C   0D   0E   0F   10  
    Object   dump   complete.

    在我的DLL中,一个函数包括以下调用:

    bool   CFoo::GetGo()
    {
            path   cPath(   "c:\\windows ",   native   );
            return   m_bGo;
    }

    path   是boost-filesystem中的类。

    主程序在BOOL   CTestGUIApp::InitInstance()中用以下方式调用DLL:

            CFoo*   cf   =   CreateFoo();
            bool   bB   =   cf-> GetGo();
            DeleteFoo(   cf   );
    一直无法想通为什么会出现内存泄漏,path   这个类中没有特别分配内存的啊。

        实际上貌似即使你不使用path类,只要在你的dll动态链接boost_filesystem-vc90-mt-gd-1_42.dll,就会出现内存泄露提示。帖子分析的原因是:

    泄漏是由于以下常量定义引起的(path_posix_windows.cpp):

        
        const   char   invalid_chars[]   =
            "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F "
            "\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1A\x1B\x1C\x1D\x1E\x1F "
            " <> :\ "/\\| ";
        //   note   that   the   terminating   '\0 '   is   part   of   the   string   -   thus   the   size   below
        //   is   sizeof(invalid_chars)   rather   than   sizeof(invalid_chars)-1.     I  
        const   std::string   windows_invalid_chars(   invalid_chars,   sizeof(invalid_chars)   );
    
        const   std::string   valid_posix(
            "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789._- "   );
             到的可能原因:MFC的内存泄漏报告有bug,他在DLL中static   变量析构前报了。

    参考:
    MFC   dumps   leaks   prematurely   when   it   exits,   instead   of   waiting   for   the  
    CRT   to   dump   leaks   following   static   data   destruction,   and   this   causes  
    spurious   leak   reports   for   objects   which   allocated   memory   before   MFC  
    was   initialized   and   which   thus   are   destroyed   after   MFC   exits.   This   is  
    commonly   observed   when   using   the   MFC   DLL   in   a   program   that   also   uses  
    the   C++   runtime   DLL.


    前无古人,后无来者

    2012年8月25日 6:20

答案

  • 把模块用LoadLibrary方式读入,然后挨个屏蔽,这样找吧。

    Debug模式所有的DLL代码都是放在内存中的,公用同一虚拟内存,所以在程序结束时的内存泄漏检查是不容易追踪到是谁在堆里分配了这一块内存。


    0xDEADBEEF

    2012年8月27日 10:27
    版主

全部回复

  • 把模块用LoadLibrary方式读入,然后挨个屏蔽,这样找吧。

    Debug模式所有的DLL代码都是放在内存中的,公用同一虚拟内存,所以在程序结束时的内存泄漏检查是不容易追踪到是谁在堆里分配了这一块内存。


    0xDEADBEEF

    2012年8月27日 10:27
    版主
  • 把模块用LoadLibrary方式读入,然后挨个屏蔽,这样找吧。

    Debug模式所有的DLL代码都是放在内存中的,公用同一虚拟内存,所以在程序结束时的内存泄漏检查是不容易追踪到是谁在堆里分配了这一块内存。


    0xDEADBEEF


           好,有空试试。但我感觉MFC的内存泄露报告确实存在问题啊!

    前无古人,后无来者

    2012年8月28日 0:57