Memory leakage caused by a pair of Ms Memory Leak search tools (leakdiag and ldgrapher) and STL class cross-DLL calls

From: http://blog.csdn.net/zhangbinjn/archive/2009/08/13/4444641.aspx

 

Today, I want to write some work-related articles and introduce the tools (leakdiag and ldgrapher ).

In the past two weeks, I can say that I have not slept well. The game running after the company's Public Beta has completed a task and the memory has reached more than 1 GB. How can I play this game and how can I play it, the recharge momentum of several hundred million in a month may fall in less than two weeks. In the past few days, the main process has been constantly searching for the cause.

Of course, the graphics engine is the most noteworthy for such a large memory leak. Only maps, light effects, and image resources occupy such a large amount of memory. However, because the engine code is maintained by another project team, we only provide some library files, so there is no way to do this, we can only test the underlying problems for every frequently called interface through the underlying layer (you have the right to speak only when evidence is provided ). However, we are disappointed with the final results. Through repeated tests, we can eliminate the underlying problems.

Of course, further, we have excluded from calling complicated pathfinding algorithms and found that this is not the reason. It's really a waste of resources, and everyone is exhausted. Memory or memory, the problem still needs to be solved.

Maybe you may see the title. I have written so many questions, maybe you will have a problem. You didn't think of finding a tool to test it. This is of course the first thing that comes to mind. I will not introduce leakdiag and ldgrapher today. I started to find many tools to try out the configuration, however, none of them reach the desired result. Finally, Microsoft's leakdiag and ldgrapher are on the right, which brings us a bright future. (Draw a conclusion: tools should be used, tools should be used, and tools should be used ). There should be many people who know its power. I would like to emphasize one more here. I believe that Chinese programmers should learn one thing, that is, good tools and good materials, good code.

There are several articles on the Internet that describe leakdiag and ldgrapher, which are also detailed:

Http://www.cppblog.com/sandy/archive/2008/08/18/59260.html

There are several points to emphasize:

1. The log is not caused by memory leakage, but by the start of your operation, which has not been released yet;

2. The log stack can be set to 1-32, so it is enough for you to locate the error code (tools settings );

3. Create several logs at the key points you think, and use the ldgrapher line chart to clearly see the memory allocation.

Of course, the reason for the problem is also the issue that most people with certain project experience will encounter cross-DLL calling of STL classes. There are also a lot of discussions on this issue, and you will have a lot to gain from Google.

Http://www.cppblog.com/fwxjj/archive/2009/06/16/87810.html

Http://www.cppblog.com/xingmuxixi/archive/2009/05/18/83281.html

The main problem we encountered this time is that when a STD: release is returned in a DLL interface, it will cause STL memory allocation exceptions and cause a large amount of memory leakage.

Well, I have written so much. If the problem is solved, I can go home and have a good night's sleep.