Memory leak while using shared_ptr - c++

Detected memory leaks!
Dumping objects ->
{9370} normal block at 0x000000C16B24C480, 24 bytes long.
Data: <`h= > 60 68 3D FB F6 7F 00 00 01 00 00 00 01 00 00 00
{8549} normal block at 0x000000C16B25CC30, 21627 bytes long.
Data: < 0 %k > FA FA FA FA FA FA FA FA 30 CC 25 6B C1 00 00 00
{5196} normal block at 0x000000C16B253320, 12839 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{192} normal block at 0x000000C16B24CE40, 24 bytes long.
Data: < m= > 20 6D 3D FB F6 7F 00 00 02 00 00 00 01 00 00 00
{191} normal block at 0x000000C16B251780, 16 bytes long.
Data: < $k > 10 DB 24 6B C1 00 00 00 00 00 00 00 00 00 00 00
{190} normal block at 0x000000C16B251410, 16 bytes long.
Data: < $k > F0 DA 24 6B C1 00 00 00 00 00 00 00 00 00 00 00
{189} normal block at 0x000000C16B2514B0, 16 bytes long.
Data: < $k > D0 DA 24 6B C1 00 00 00 00 00 00 00 00 00 00 00
{188} normal block at 0x000000C16B2516E0, 16 bytes long.
Data: < $k > B0 DA 24 6B C1 00 00 00 00 00 00 00 00 00 00 00
{187} normal block at 0x000000C16B251690, 16 bytes long.
Data: < $k > 90 DA 24 6B C1 00 00 00 00 00 00 00 00 00 00 00
{186} normal block at 0x000000C16B251370, 16 bytes long.
Data: <p $k > 70 DA 24 6B C1 00 00 00 00 00 00 00 00 00 00 00
{185} normal block at 0x000000C16B251230, 16 bytes long.
Data: <P $k > 50 DA 24 6B C1 00 00 00 00 00 00 00 00 00 00 00
{184} normal block at 0x000000C16B24DA50, 224 bytes long.
Data: <0 %k #3%k > 30 12 25 6B C1 00 00 00 40 33 25 6B C1 00 00 00
{156} normal block at 0x000000C16B24C4E0, 24 bytes long.
Data: <P $k # $k > 50 DA 24 6B C1 00 00 00 40 CE 24 6B C1 00 00 00
{155} normal block at 0x000000C16B24C300, 32 bytes long.
Data: <../dataset/refer> 2E 2E 2F 64 61 74 61 73 65 74 2F 72 65 66 65 72
{154} normal block at 0x000000C16B250AB0, 16 bytes long.
Data: < k > A8 F4 09 6B C1 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.
'3DMM_1st.exe' (Win32): Loaded 'C:\Windows\System32\kernel.appcore.dll'. Cannot find or open the PDB file.
The program '[36392] 3DMM_1st.exe' has exited with code 1 (0x1).strong text
Can anyone help me? I got a problem relating to memory leaks. I don't know how to solve it, can anyone can give some suggestions, it will greatly be appreciated.
Here are some info about my code. I created a struct named ObjectData and a class named ObjectLoader just as follows:
struct ObjectData {
std::vector <glm::vec3> vertices, normals, colors;
std::vector <glm::vec2> texCoords;
std::vector <unsigned int> vIndices, uIndices, nIndices;
};
class ObjectLoader {
private:
std::tr1::shared_ptr<ObjectData> object;
bool hasUV, hasNormals, hasColor, colorChecked, indexChecked;
std::string parseString(std::string src, std::string code);
std::vector<glm::vec3> parseVerColor(std::string src, std::string code);
glm::vec2 parseVec2(std::string src, std::string code);
glm::vec3 parseVec3(std::string src, std::string code);
void addIndices(std::string str);
void checkIndices(std::string str);
void checkColors(std::string str);
void loadObjects(std::string objPath);
public:
ObjectLoader(std::string objName);
~ObjectLoader();
std::tr1::shared_ptr<ObjectData> getModel();
};
Here is the getModel() and ObjectLoader() implementation code:
std::tr1::shared_ptr<ObjectData> ObjectLoader::getModel() {
return object;
}
ObjectLoader::ObjectLoader(std::string objName) {
indexChecked = false;
colorChecked = false;
std::string fileName = objName;
object = std::tr1::shared_ptr<ObjectData>(new ObjectData());
}
When I test my code I get the problem related to the memory leaks.
Here is my test code:
std::tr1::shared_ptr<ObjectLoader> loader = std::tr1::shared_ptr<ObjectLoader>(new ObjectLoader(fileName));
std::tr1::shared_ptr<ObjectData> data = loader->getModel();
_CrtDumpMemoryLeaks();

You have a problem detecting the leaks because of the scope of the std::shared_ptr.
In the code;
std::tr1::shared_ptr<ObjectLoader> loader = std::tr1::shared_ptr<ObjectLoader>(new ObjectLoader(fileName));
std::tr1::shared_ptr<ObjectData> data = loader->getModel();
_CrtDumpMemoryLeaks();
The loader and data destructors, and hence the deletions, do not run until after the _CrtDumpMemoryLeaks(); function reports the leaks.
Adding an extra scope can help with this, else the code needs to be restructured.
{
std::tr1::shared_ptr<ObjectLoader> loader = std::tr1::shared_ptr<ObjectLoader>(new ObjectLoader(fileName));
std::tr1::shared_ptr<ObjectData> data = loader->getModel();
} // destructors run here...
_CrtDumpMemoryLeaks();

Related

memory leak in osgearth

My goal is using library OSGEarth to make a MFC project that can display the model "openstreetmap.earth". I finished this and can see the the earth.But every time when i close the project, the output window in vs2015 say there are memory leaks in the program.
Here is the window output:
Detected memory leaks!
Dumping objects ->
{306240} normal block at 0x00000000076902F0, 16 bytes long.
Data: <0,i > 30 2C 69 07 00 00 00 00 00 00 00 00 00 00 00 00
{306239} normal block at 0x0000000007692C30, 9 bytes long.
Data: <Pragma: > 50 72 61 67 6D 61 3A 20 00
{303648} normal block at 0x0000000007693040, 16 bytes long.
Data: < 5i > 90 35 69 07 00 00 00 00 00 00 00 00 00 00 00 00
{303647} normal block at 0x0000000007693590, 9 bytes long.
Data: <Pragma: > 50 72 61 67 6D 61 3A 20 00
{301180} normal block at 0x00000000076938B0, 16 bytes long.
Data: <`8i > 60 38 69 07 00 00 00 00 00 00 00 00 00 00 00 00
{301179} normal block at 0x0000000007693860, 9 bytes long.
Data: <Pragma: > 50 72 61 67 6D 61 3A 20 00
{297799} normal block at 0x0000000007691060, 16 bytes long.
Data: < i > 10 10 69 07 00 00 00 00 00 00 00 00 00 00 00 00
I examined the program and found that when I delete this code m_Model = osgDB::readNodeFile(m_strModelName); there is no more memory leaks.
void COSGEarth::InitSceneGraph(void)
{
// Init the main Root Node/Group
m_Root = new osg::Group;
// Load the Model from the model name,
//delete below line, no memory leak
m_Model = osgDB::readNodeFile(m_strModelName);
if (!m_Model) return;
// Optimize the model
osgUtil::Optimizer optimizer;
optimizer.optimize(m_Model.get());
optimizer.reset();
// Add the model to the scene
m_Root->addChild(m_Model.get());
}
I defined m_Model as osg::ref_ptr<osg::Node> m_Model. This is Intelligent pointer.
Why there are memory leaks and how I can solve this issue?
Here is source code :http://bbs.osgchina.org/forum.php?mod=attachment&aid=NzIwNnwzZWYxZDIyZjlhOGY1MWFjZjhiNGFiMWYwMTc5YmJlNXwxNTEyMzc5ODE2&request=yes&_f=.zip
I believe these reported "leaks" are false positives. Refer to this thread that explains why:
http://forum.openscenegraph.org/viewtopic.php?t=1475

Memory Leak with Openssl when allocating memory for X509_STORE

I am using openssl in my project. When I exit my application I get "Detected memory leaks!" in Visual Studio 2013.
Detected memory leaks!
Dumping objects ->
{70202} normal block at 0x056CB738, 12 bytes long.
Data: <8 j > 38 E8 6A 05 00 00 00 00 04 00 00 00
{70201} normal block at 0x056CB6E8, 16 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{70200} normal block at 0x056CB698, 20 bytes long.
Data: < l > 00 00 00 00 E8 B6 6C 05 00 00 00 00 04 00 00 00
{70199} normal block at 0x056AE838, 12 bytes long.
Data: < l > 04 00 00 00 98 B6 6C 05 00 00 00 00
{70198} normal block at 0x056CB618, 64 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{70197} normal block at 0x056CB578, 96 bytes long.
Data: < l 3 3 > 18 B6 6C 05 00 FE C0 33 C0 FD C0 33 08 00 00 00
Object dump complete.
When I add
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
_CrtSetBreakAlloc(70202);
to main main function I always get a breakpoint at the allocation of the x509 store, no matter for which of the 6 numbers (70202,...) I set the break point.
I initialize and uninitialize the x509 store in a class' constructor and destructor (see below).
Is there anything else I need to look out for when using the x509_STORE?
Foo::CSCACerts::CSCACerts(void)
{
m_store = X509_STORE_new();
}
Foo::CSCACerts::~CSCACerts(void)
{
X509_STORE_free( m_store );
}

(VS15 C++) Got a Visual Leak Detector report, but what now?

because of some (strange) problems in my C++-project I used Visual Leak Detector (for the first time), to check the project on memory leaks.
So I got i.a. the follwoing reports:
WARNING: Visual Leak Detector detected memory leaks!
---------- Block 4 at 0x004D07B0: 200 bytes ----------
Leak Hash: 0xD2D1B4A0, Count: 1, Total 200 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
28 75 14 03 00 00 00 00 01 00 00 00 00 00 00 00 (u...... ........
9A 99 99 99 99 99 B9 3F 50 00 00 00 0A 00 00 00 .......? P.......
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 74 3F 14 00 00 00 BA FF FF FF {..G.zt? ........
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 84 3F 00 00 00 00 64 00 00 00 {..G.z.? ....d...
00 00 00 00 01 00 00 00 14 00 00 00 46 00 00 00 ........ ....F...
00 00 00 00 64 00 00 00 00 00 00 00 F4 01 00 00 ....d... ........
01 00 00 00 B8 E2 13 03 F0 AD 18 03 00 00 00 00 ........ ........
C8 E2 13 03 C8 AB 18 03 00 00 00 00 78 E3 13 03 ........ ....x...
B8 AC 18 03 00 00 00 00 68 E2 13 03 E8 AC 18 03 ........ h.......
00 00 00 00 14 00 00 00 01 00 00 00 64 00 00 00 ........ ....d...
01 00 00 00 00 00 00 00 ........ ........
---------- Block 20 at 0x004D0880: 200 bytes ----------
Leak Hash: 0xD2D1B4A0, Count: 1, Total 200 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
78 74 14 03 00 00 00 00 01 00 00 00 00 00 00 00 xt...... ........
9A 99 99 99 99 99 B9 3F 50 00 00 00 0A 00 00 00 .......? P.......
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 74 3F 14 00 00 00 BA FF FF FF {..G.zt? ........
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 84 3F 00 00 00 00 64 00 00 00 {..G.z.? ....d...
00 00 00 00 01 00 00 00 14 00 00 00 46 00 00 00 ........ ....F...
00 00 00 00 64 00 00 00 00 00 00 00 F4 01 00 00 ....d... ........
01 00 00 00 38 E2 13 03 00 F0 15 03 00 00 00 00 ....8... ........
B8 E1 13 03 88 00 7F 05 00 00 00 00 08 E2 13 03 ........ ........
20 FF 7E 05 00 00 00 00 E8 E1 13 03 80 FF 7E 05 ..~..... ......~.
00 00 00 00 14 00 00 00 01 00 00 00 64 00 00 00 ........ ....d...
01 00 00 00 00 00 00 00 ........ ........
---------- Block 31 at 0x0053E1B8: 72 bytes ----------
Leak Hash: 0x3F88029B, Count: 1, Total 72 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
60 BC 55 00 40 3E 80 05 A0 3F 80 05 A0 3F 80 05 `.U.#>.. .?...?..
60 BB 55 00 20 34 18 03 00 00 00 00 00 00 00 00 `.U..4.. ........
00 00 00 00 20 00 00 00 2F 00 00 00 80 BC 55 00 ........ /.....U.
00 2E 18 03 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
20 00 00 00 2F 00 00 00 ..../... ........
---------- Block 33 at 0x0055BB60: 8 bytes ----------
Leak Hash: 0xA49C5AA6, Count: 1, Total 8 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
C8 E1 53 00 00 00 00 00
..S..... ........
//And many more...
Unfortunatly I do not understand, what VLD wants to say is the problem.
With a double-click on the "f:\dd..."-lines it should set my courser to the line with the problem, shouldn´t it? But it dosen´t.
My question is now: How do I get to the area of the problem or in other words "how do I read these reports"?
In addition:
I use Visual Studio 2015
The project is a C++ Windows Forms Project
I included the vld.h in the additional includes and the lib-directory to the additional libraries of the project
In the main() I use #include <vld.h> and _CrtDumpMemoryLeaks();
EDIT:
My Main (a reduced version, but gives similar reports):
//some class-includes
#include <vld.h>
using namespace System;
using namespace System::Windows::Forms;
using namespace std;
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
[STAThread]
void Main()
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Experiment* experiment = new Experiment();
Experiment_List* running_experiments = new Experiment_List();
while(!experiment->end) {
experiment= new Experiment();
LASS::MainWindow form(experiment, running_experiments);
form.ShowDialog();
if(!experiment->end){
running_experiments->register_experiment(experiment);
}
}
running_experimente->end_all();
_CrtDumpMemoryLeaks();
exit(0);
}
Unfortunatley there are about 40 classes, that I do not want to post...
I don't know where the problem exact is.
For me, it helps to run the program in RELEASE Mode, instead of DEBUG mode.
I suppose, my problem is the handling of managed and unmanaged code together.
I have unmanaged code inside managed code.
It seams as if CLR use a different new operator in Debug mode. Not as conform as the c++ standard.
According to: Using push_back() for STL List in C++ causes Access Violation, Crash
If you malloc() a C++ class, no constructors will be called for any of
that class's fields
And the VS will step into a constructor in class new_scalar.cpp.
Folks say that is depending of the Visual Leak Detector (VLD). You use them in your includes.
In the End, try to distinguish your code with
#pragma managed
and
#pragma unmanaged
And run in RELEASE mode.

I want to know pointer holds particular address at the time of debugging

I got memory dump by using #define _CRTDBG_MAP_ALLOC in output window.
Detected memory leaks!
Dumping objects ->
{1078301} normal block at 0x0AB2D840, 48 bytes long.
Data: <2 0 1 4 - 0 9 - > 32 00 30 00 31 00 34 00 2D 00 30 00 39 00 2D 00
{975444} normal block at 0x08D21138, 36 bytes long.
Data: < = = pa > A4 3D C0 08 B0 3D C0 08 01 00 00 00 70 61 BE 08
{975443} normal block at 0x0CE96610, 32 bytes long.
Data: <,X \ pa > 2C 58 C0 08 5C 90 BF 08 01 00 00 00 70 61 BE 08
{975438} normal block at 0x0CE6B1D8, 32 bytes long.
Data: 50 90 BF 08 5C 90 BF 08 01 00 00 00 08 E3 D1 08
{736753} normal block at 0x0CEAA878, 16384 bytes long.
Data: < / / > D8 2F D2 08 D8 2F D2 08 03 00 00 00 00 00 00 00
{736744} normal block at 0x0CEA8838, 8192 bytes long.
Data: <8 8 > 38 0B E2 0C 38 88 EA 0C 01 00 00 00 01 00 00 00
{736738} normal block at 0x0CEA47F8, 16384 bytes long.
Data: < G > 00 00 00 00 F8 47 EA 0C 03 00 00 00 00 00 00 00
{736729} normal block at 0x0CE105A8, 8192 bytes long.
Data: <( > 28 14 D1 08 A8 05 E1 0C 01 00 00 00 CD CD CD CD
{736723} normal block at 0x0CEA07B8, 16384 bytes long.
Data: < G 8 > F8 47 EA 0C 38 88 EA 0C 03 00 00 00 00 00 00 00
{736713} normal block at 0x0CE1E440, 8192 bytes long.
Data: < # > A8 05 E1 0C 40 E4 E1 0C 01 00 00 00 CD CD CD CD
{736707} normal block at 0x0CE1A400, 16384 bytes long.
Data: < > B8 07 EA 0C B8 07 EA 0C 03 00 00 00 00 00 00 00
{736698} normal block at 0x0CE36B18, 8192 bytes long.
Data: <# k > 40 E4 E1 0C 18 6B E3 0C 01 00 00 00 CD CD CD CD
{736692} normal block at 0x0CE163C0, 16384 bytes long.
Data: < > 00 A4 E1 0C 00 A4 E1 0C 03 00 00 00 00 00 00 00
{736682} normal block at 0x0CE44230, 8192 bytes long.
Data: < k 0B > 18 6B E3 0C 30 42 E4 0C 01 00 00 00 CD CD CD CD
{736676} normal block at 0x0CE3E7F8, 16384 bytes long.
Data: < c c > C0 63 E1 0C C0 63 E1 0C 03 00 00 00 00 00 00 00
{736666} normal block at 0x0CE4B6F0, 8192 bytes long.
Data: <0B > 30 42 E4 0C F0 B6 E4 0C 01 00 00 00 CD CD CD CD
{736660} normal block at 0x0CE3A7B8, 16384 bytes long.
Data: < > F8 E7 E3 0C F8 E7 E3 0C 03 00 00 00 00 00 00 00
{736650} normal block at 0x0CE47388, 8192 bytes long.
Data: < s > F0 B6 E4 0C 88 73 E4 0C 01 00 00 00 CD CD CD CD
{736644} normal block at 0x0CE0C568, 16384 bytes long.
Data: < > B8 A7 E3 0C B8 A7 E3 0C 03 00 00 00 00 00 00 00
{736634} normal block at 0x0CE20B38, 8192 bytes long.
Data: < s 8 > 88 73 E4 0C 38 0B E2 0C 01 00 00 00 CD CD CD CD
{736628} normal block at 0x0CE23B70, 16384 bytes long.
Data: 68 C5 E0 0C 68 C5 E0 0C 03 00 00 00 00 00 00 00
{663741} normal block at 0x0CDB6EF0, 60 bytes long.
Data: 50 F2 BF 08 24 6F C0 08 01 00 00 00 30 75 00 00
{1923} normal block at 0x08D20DE8, 8 bytes long.
Data: <#] d > 40 5D BE 08 64 C0 D1 08
{1922} normal block at 0x08D22E10, 56 bytes long.
Data: 70 5C BE 08 00 00 00 00 CD CD CD CD E8 0D D2 08
{1900} normal block at 0x08D27018, 16384 bytes long.
Data: < > F0 E2 D1 08 F0 E2 D1 08 03 00 00 00 00 00 00 00
{1894} normal block at 0x08D22FD8, 16384 bytes long.
Data: 70 3B E2 0C 70 3B E2 0C 03 00 00 00 00 00 00 00
{1883} normal block at 0x08D22900, 144 bytes long.
Data: 43 00 3A 00 5C 00 55 00 73 00 65 00 72 00 73 00
Object dump complete.
Now debegger hits the breakpoint. In watch window, at the time of debuging I add {,,msvcr100d.dll}_crtBreakAlloc in name columm and I add memory location 736723 which is the memory block number in the dump mentioned above in the value columm. This leak happens in a function that loops.
When I continue debugging, it breaks at the memory block number that is entered in watch window see fig 1
press break in the window
see fig 2
_CrtDbgBreak holds 0x69595280.thats where memory leak happens
Now, how do I get to know the pointer that holds particular address loaction at the time of debugging.
Thanks in Advance
Avinash V
The program already breaks there, so you should go the call stack window in Visual studio and find the source code there, then you can find the source code which calls the memory allocation function, that is what you're looking for.
As you're using the allocation number to tracking memory leaks, the allocation number can change if the program doesn't run under previous conditions. Please refer: Finding Memory Leaks Using the CRT Library

Could this be a false positive memory leak report?

I am testing my dll that I created. It in turn use several other dlls. My Dll tester application reports memory leaks when I start the test application and exit without doing anything except loading dll using LoadLibrary. It doesn't show the exact files in my dll source code. There are no leaks if I don't load the dll. It is an MFC dll and has App class. I removed everything from the dll's app class so it does nothing but I still get memory leaks report when I load it. I created another set of dummy dll and test application but that doesn't report any leaks so it has to do with my original dll, perhaps its linkage with other dlls?
I have tried using _crtBreakAlloc = {allocation_#}; technique but it doesn't stop the debugger either. I am quite lost if this memory leak is real. I see from documentation it can report false positive. Could this be false positive just because my dll is linked to bunch of other dlls? I can't think of anything else because I have commented out all functionality from dll.
Here is the memory leak erros
Detected memory leaks!
Dumping objects ->
{250} client block at 0x00567E40, subtype c0, 64 bytes long.
a CDynLinkLibrary object at $00567E40, 64 bytes long
a CDynLinkLibrary object at $00567E40, 64 bytes long
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {244} normal block at 0x00567C20, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {243} normal block at 0x00567BC8, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {242} normal block at 0x00567B58, 52 bytes long.
Data: < x > E4 B8 07 78 11 00 00 00 11 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {241} normal block at 0x00566C08, 40 bytes long.
Data: < x > E4 B8 07 78 0B 00 00 00 0B 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {240} normal block at 0x00566BA8, 32 bytes long.
Data: < x > E4 B8 07 78 07 00 00 00 07 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {239} normal block at 0x00566B50, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {238} normal block at 0x00566AE0, 46 bytes long.
Data: < x > E4 B8 07 78 0E 00 00 00 0E 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {237} normal block at 0x00566A70, 48 bytes long.
Data: < x > E4 B8 07 78 0F 00 00 00 0F 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {235} normal block at 0x005676B0, 42 bytes long.
Data: < x > E4 B8 07 78 0C 00 00 00 0C 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {234} normal block at 0x00567658, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {233} normal block at 0x00567600, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {232} normal block at 0x00567590, 50 bytes long.
Data: < x > E4 B8 07 78 10 00 00 00 10 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {231} normal block at 0x00567538, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {230} normal block at 0x005674E0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {229} normal block at 0x00567488, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {228} normal block at 0x00567430, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {227} normal block at 0x005673D8, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {226} normal block at 0x00567380, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {225} normal block at 0x00567328, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {224} normal block at 0x005672C0, 40 bytes long.
Data: < x > E4 B8 07 78 0B 00 00 00 0B 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {223} normal block at 0x00567268, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {222} normal block at 0x00567200, 44 bytes long.
Data: < x > E4 B8 07 78 0D 00 00 00 0D 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {221} normal block at 0x00567198, 38 bytes long.
Data: < x > E4 B8 07 78 0A 00 00 00 0A 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {220} normal block at 0x00567140, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {219} normal block at 0x005670E8, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {218} normal block at 0x00567080, 38 bytes long.
Data: < x > E4 B8 07 78 0A 00 00 00 0A 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {217} normal block at 0x00567028, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {216} normal block at 0x00566FD0, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {215} normal block at 0x00566F78, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {214} normal block at 0x00566F18, 36 bytes long.
Data: < x > E4 B8 07 78 09 00 00 00 09 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {213} normal block at 0x00566EC0, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {212} normal block at 0x00566E68, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {211} normal block at 0x00566E10, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {210} normal block at 0x00566DB8, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {209} normal block at 0x00566D60, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {208} normal block at 0x00566D08, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {207} normal block at 0x00566CB0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {206} normal block at 0x00561918, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {205} normal block at 0x005618C0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {204} normal block at 0x00561868, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {202} normal block at 0x005669F8, 60 bytes long.
Data: < x > E4 B8 07 78 15 00 00 00 15 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {201} normal block at 0x00566988, 46 bytes long.
Data: < x > E4 B8 07 78 0E 00 00 00 0E 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {200} normal block at 0x00566920, 42 bytes long.
Data: < x > E4 B8 07 78 0C 00 00 00 0C 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {199} normal block at 0x005668C8, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {198} normal block at 0x00566868, 32 bytes long.
Data: < x > E4 B8 07 78 07 00 00 00 07 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {197} normal block at 0x00566800, 44 bytes long.
Data: < x > E4 B8 07 78 0D 00 00 00 0D 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {196} normal block at 0x00566790, 50 bytes long.
Data: < x > E4 B8 07 78 10 00 00 00 10 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {195} normal block at 0x00566718, 60 bytes long.
Data: < x > E4 B8 07 78 15 00 00 00 15 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {194} normal block at 0x005666C0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {193} normal block at 0x00566040, 48 bytes long.
Data: < x > E4 B8 07 78 0F 00 00 00 0F 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {192} normal block at 0x00561C98, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {81} normal block at 0x00561BA0, 32 bytes long.
Data: < x > E4 B8 07 78 07 00 00 00 07 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {80} normal block at 0x00561B48, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {79} normal block at 0x00561AE0, 44 bytes long.
Data: < x > E4 B8 07 78 0D 00 00 00 0D 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {78} normal block at 0x00561A80, 34 bytes long.
Data: < x > E4 B8 07 78 08 00 00 00 08 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {77} normal block at 0x00561A20, 30 bytes long.
Data: < x > E4 B8 07 78 06 00 00 00 06 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {76} normal block at 0x005613D0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {75} normal block at 0x005619A8, 56 bytes long.
Data: < x > E4 B8 07 78 13 00 00 00 13 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {74} normal block at 0x00561378, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {72} normal block at 0x005617F8, 48 bytes long.
Data: < x > E4 B8 07 78 0F 00 00 00 0F 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {71} normal block at 0x005617A0, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {70} normal block at 0x00561748, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {69} normal block at 0x005616D0, 54 bytes long.
Data: < x > E4 B8 07 78 12 00 00 00 12 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {68} normal block at 0x00561670, 34 bytes long.
Data: < x > E4 B8 07 78 08 00 00 00 08 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {67} normal block at 0x00561618, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {66} normal block at 0x005615B8, 36 bytes long.
Data: < x > E4 B8 07 78 09 00 00 00 09 00 00 00 01 00 00 00
Object dump complete.
Is there another way I can double check the memory leaks don't exist? I installed deleaker as well but it is buggy program, it holds on pdb files and was not releasing it...that caused me more pain.
According to the following MSKB article, this is probably expected:
Memory leaks are reported when you use multiple MFC DLLs
Quoting from the linked page:
These memory leaks are reported when multiple versions of the MFC DLL
are loaded in the same process. Since MFC extension (AFXDLL) DLLs
require the exact same MFC DLL as the call application, this problem
can only occur when using MFC regular (USRDLL) DLLs or ActiveX
Controls (OCX) that use the shared version of MFC.
The most common case is mixing ANSI (MFC4xd.DLL) and UNICODE
(MFC4xxUd.DLL) versions of MFC in the same process. This can also
occur when mixing MFC42d.DLL and MFC40d.DLL.
And as far as resolving the "problem" goes:
These memory leak notifications are false, and can be ignored. Since
neither copy of MFC knows about the other ones, it's not easy to stop
these false leaks from being reported.