VC2008 C++内存泄漏

发布于 2024-12-11 06:39:26 字数 2574 浏览 0 评论 0原文

请注意,我的英语水平很低。但我会尽力解释。


我在 Visual Studio 2008 sp1 中制作了一个 mfc 项目。

该项目包含一个由 2008/sp1/native C++ 制作的静态库,

问题在于步骤:

1) 在 mfc 项目上构建并启动调试
2) 单击主窗口上的 x 按钮或 alt+f4 退出程序
3)主窗口立即关闭
4)但是当我查看taskmgr的进程选项卡时,它仍然存在。
5)如果我尝试在taskmgr上杀死mfc项目进程,它会立即杀死
6) 但 Visual Studio 仍然处于调试模式,并且 IDE 需要很长时间才能恢复正常。
7)时间为5~10分钟
8)并输出日志,检测到内存泄漏!!
9)日志非常大,几乎有11兆字节的文本


我找到了重点。
1)静态库总是在启动时使用new运算符创建库的主功能类的实例(启动是静态时,在main前面)
2)静态库的构造函数有下一个代码
注意:很抱歉,我尝试在此编辑器中查找“代码”选项卡,但我无法制作代码部分,因此我编写代码并订购“br”html 标签。


VPHYSICS::VPHYSICS(){
       m_tickflowed = 0;
       QueryPerformanceFrequency(&cpu_freq);
       SetTickTime(30);

       m_state[VPHYSTATE_SPEED_MAX]=SPEED_SCALAR_MAX;
       m_state[VPHYSTATE_LIMITED_ACCELARATION]=FALSE;
       m_state[VPHYSTATE_FRICTIONENABLE]=TRUE;
       m_state[VPHYSTATE_FRICTIONFACTOR]=1.0f;
       m_state[VPHYSTATE_GRAVITY]=9.8065f;
       m_state[VPHYSTATE_ENGINESPEED_DELAY_HIGH]=0.0f;
       m_state[VPHYSTATE_ENGINESPEED_DELAY_LOW]=0.0f;
       m_state[VPHYSTATE_FRICTION_RATIO]=1.0f;
       m_state[VPHYSTATE_DIMENSION_GLOBAL]=2;
       m_state[VPHYSTATE_COLLISION_UNFRICTIONABLE]=TRUE;
       m_state[VPHYSTATE_PAULI_EXCLUSION_ENABLE]=TRUE;
       m_state[VPHYSTATE_PAULI_EXCLUSION_RATIO]=1.0f;
       m_state[VPHYSTATE_FRICTION_SMOOTHLY]=1.0f;
       m_state[VPHYSTATE_COLLHANDLER_OUTER]=TRUE;
       m_dwSuspendedCount=0;
       InitializeCriticalSection(&m_criRegister);
       InitializeCriticalSection(&cri_out);
       ZeroMemory(m_objs,sizeof(m_objs));
       m_bThreadDestroy=FALSE;
       m_hPhysicalHandle=0;
       m_nPhysicalThread1ID=0;
       m_nTimeMomentTotalCount=0;
       m_hGarbageCollector=0;
       m_nGarbageCollectorID=0;
       m_PhyProcessIterID=NULL;
       for(DWORD i = 1 ; i < MAX_OBJECT_NUMBER ; i++)
       {
           m_objAvaliable.push_back(i);
       }
  }

//这段代码是我的静态库,使用游戏的物理引擎。

问题出在销毁这个实例时。
当删除操作符调用时(在程序结束时),需要很长时间。
当我删除

for(DWORD i = 1 ; i < MAX_OBJECT_NUMBER ; i++)
    {
        m_objAvaliable.push_back(i);
    }

或减少MAX_OBJECT_NUMBER(最初是#define MAX_OBJECT_NUMBER 100000,但我将其减少到5或10)时,“长时间”消失了!!< br>
“m_objAvaliable”的类型为 std::list
该成员变量似乎不会导致内存泄漏。 (因为这个容器没有任何堆分配的关系)
包括这个库的其他项目没有这个问题。
(但包含在 mfc 项目中是第一次,在这种情况下我只能看到这个问题)
有人想出解决这个问题的办法吗???
如果您想了解更多信息,请评论本文。我会尽快回复
更多:它只发生在调试模式下。在Release模式下,不会出现这个问题。

please note my english skill is very low. but i'll try my best to explain.

I making a mfc project in Visual Studio 2008 sp1.

this Project included a static library that maked by 2008/sp1/native C++

the problem is that step:

1) build and start debug on mfc project
2) click x button on main window or alt+f4 to exit program
3) the main window is closed at once
4) but when i looking process tab of taskmgr, it still alive.
5) if i try kill mfc project process on taskmgr, it killed at once
6) but visual studio still debugging mode and very long time taken to the IDE is returnning normal.
7) the time is 5~10 minutes
8) and output log, detected memory leaks!!
9) the log is very large almost 11megabytes text

and i find the point.
1) the static library always create a library's main functional class's instance on start-up, using new operator (the start-up is static time, front of main)
2) static library's constructor has next code
note : i'm sorry i try to looking the 'Code' tab in this editor but i can't make code section so i write the code and ordering "br" html tag.

VPHYSICS::VPHYSICS(){
       m_tickflowed = 0;
       QueryPerformanceFrequency(&cpu_freq);
       SetTickTime(30);

       m_state[VPHYSTATE_SPEED_MAX]=SPEED_SCALAR_MAX;
       m_state[VPHYSTATE_LIMITED_ACCELARATION]=FALSE;
       m_state[VPHYSTATE_FRICTIONENABLE]=TRUE;
       m_state[VPHYSTATE_FRICTIONFACTOR]=1.0f;
       m_state[VPHYSTATE_GRAVITY]=9.8065f;
       m_state[VPHYSTATE_ENGINESPEED_DELAY_HIGH]=0.0f;
       m_state[VPHYSTATE_ENGINESPEED_DELAY_LOW]=0.0f;
       m_state[VPHYSTATE_FRICTION_RATIO]=1.0f;
       m_state[VPHYSTATE_DIMENSION_GLOBAL]=2;
       m_state[VPHYSTATE_COLLISION_UNFRICTIONABLE]=TRUE;
       m_state[VPHYSTATE_PAULI_EXCLUSION_ENABLE]=TRUE;
       m_state[VPHYSTATE_PAULI_EXCLUSION_RATIO]=1.0f;
       m_state[VPHYSTATE_FRICTION_SMOOTHLY]=1.0f;
       m_state[VPHYSTATE_COLLHANDLER_OUTER]=TRUE;
       m_dwSuspendedCount=0;
       InitializeCriticalSection(&m_criRegister);
       InitializeCriticalSection(&cri_out);
       ZeroMemory(m_objs,sizeof(m_objs));
       m_bThreadDestroy=FALSE;
       m_hPhysicalHandle=0;
       m_nPhysicalThread1ID=0;
       m_nTimeMomentTotalCount=0;
       m_hGarbageCollector=0;
       m_nGarbageCollectorID=0;
       m_PhyProcessIterID=NULL;
       for(DWORD i = 1 ; i < MAX_OBJECT_NUMBER ; i++)
       {
           m_objAvaliable.push_back(i);
       }
  }

//this code is my static library, using Physics Engine of Game.

and the problem is when destroying this instace.
when the delete operator calling(at end of program), it takes very long time.
when i remove the

for(DWORD i = 1 ; i < MAX_OBJECT_NUMBER ; i++)
    {
        m_objAvaliable.push_back(i);
    }

, or decrease MAX_OBJECT_NUMBER(originally it was #define MAX_OBJECT_NUMBER 100000, but i decrease it to 5 or 10), the 'long time' is disappeared!!

the type of 'm_objAvaliable' is std::list<DWORD>
this member variable seems not causing of memory leak. (because this container don't have any relation of heap allocation)
and the other project including this library don't has this problem.
(but included by mfc project is first time and i can see only this problem in this case)
Does anyone imagine a solution that problem???
if you want more information, comment to this article. i'll reply ASAP

more : it only happen in DEBUG mode. on Release mode, this problem don't occur.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

删除会话 2024-12-18 06:39:26

我相信您遇到的问题实际上根本不是问题。 MFC 使用它自己的 new 调试版本(在发布模式下,它使用常规的默认 new)。 MFC 这样做是为了尝试并帮助告诉您存在内存泄漏。

问题是,我认为静态库中对象的释放是在 MFC 决定转储它认为尚未正确释放的任何分配之后发生的。鉴于您有如此多的对象,将这些东西转储到控制台需要花费很长时间。

归根结底,MFC 认为存在内存泄漏,而实际上并不存在。

您的解决方案是:

  1. 使用 DEBUG NEW 停止 MFC。删除 MFC 项目中任何 #define new DEBUG_NEW 行。当然,此方法的缺点是,如果您无意中创建了真正的内存泄漏,它无法跟踪它们。

  2. 静态库中有某种初始化、反初始化函数。当 MFC 应用程序退出时,在 MFC 开始遍历它认为仍然存在的分配之前,调用反初始化函数。

I believe the problem you are experiencing is not, in fact, a problem at all. MFC uses it's own debug version of new (in Release mode, it uses the regular, default new). MFC does this so it can try and be helpful in telling you that you have memory leaks.

Trouble is, I think that you deallocation of the objects in the static library is occurring after MFC has decided to dump any allocations it thinks haven't been properly deallocated. Given that you have so many objects, It's spending an awfully long time dumping this stuff to the console.

At the end of the day, MFC thinks there are memory leaks when there aren't.

Your solutions are:

  1. Stop MFC using DEBUG NEW. Remove any lines in your MFC project that are #define new DEBUG_NEW. The disadvantage to this method is that, of course, if you inadvertently create real memory leaks, it can't track them.

  2. Have some kind of initialisation, de-initialisation functions in your static library. Call the de-initialisation function when your MFC application exits, prior to when MFC starts to trawl through allocations it still thinks exist.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文