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
Related
I'm using _CrtSetBreakAlloc() function to track down memory leaks in debugger builds of my MFC project. (Here's the code from my previous question.)
That technique works for as long as the Allocation order number remains the same. But in many cases it does not. For instance, here's two reports that I'm getting now:
First run:
Detected memory leaks!
Dumping objects ->
{222861} normal block at 0x000002BDF58347C0, 240 bytes long.
Data: <C : \ P r o g r > 43 00 3A 00 5C 00 50 00 72 00 6F 00 67 00 72 00
{222860} normal block at 0x000002BDEFBA52A0, 16 bytes long.
Data: < > 10 AF B7 EF BD 02 00 00 00 00 00 00 00 00 00 00
{222859} normal block at 0x000002BDEFB7AF10, 40 bytes long.
Data: < R G > A0 52 BA EF BD 02 00 00 C0 47 83 F5 BD 02 00 00
Object dump complete.
Second run:
Detected memory leaks!
Dumping objects ->
{222422} normal block at 0x00000123DDB67540, 224 bytes long.
Data: <C : \ P r o g r > 43 00 3A 00 5C 00 50 00 72 00 6F 00 67 00 72 00
{222419} normal block at 0x00000123DDBA9C50, 16 bytes long.
Data: < # > 80 16 B7 DD 23 01 00 00 00 00 00 00 00 00 00 00
{222418} normal block at 0x00000123DDB71680, 40 bytes long.
Data: <P # #u # > 50 9C BA DD 23 01 00 00 40 75 B6 DD 23 01 00 00
Object dump complete.
So I'm wondering, if there's a function, or a way to rewrite _CrtSetBreakAlloc to make it trigger a breakpoint on the memory contents? For instance, in my case, when the memory gets Unicode-16 string "C:\Progr" written into it.
There is already a _CrtSetAllocHook. But how should this help? The data is set AFTER the allocation. So no hook will take place when the data you want to trigger is written into the memory allocated.
The only way I see is to use _CrtDoForAllClientObjects and search through all allocated blocks.
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();
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 );
}
My compiler is Visual VC++ 2013. The following simplest program will cause a few memory leaks.
Why? How to fix it?
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#include <cstdlib>
#include <iostream>
#include <locale>
using namespace std;
int main()
{
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_LEAK_CHECK_DF);
cout.imbue(locale("")); // If this statement is commented, then OK.
}
The debug window outputs as follows:
Detected memory leaks!
Dumping objects ->
{387} normal block at 0x004FF8C8, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{379} normal block at 0x004FF678, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{352} normal block at 0x004FE6E8, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{344} normal block at 0x004FE498, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{318} normal block at 0x004FD5C8, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{308} normal block at 0x004F8860, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
Object dump complete.
Detected memory leaks!
Dumping objects ->
{387} normal block at 0x004FF8C8, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{379} normal block at 0x004FF678, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{352} normal block at 0x004FE6E8, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{344} normal block at 0x004FE498, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{318} normal block at 0x004FD5C8, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
{308} normal block at 0x004F8860, 12 bytes long.
Data: <z h - C N > 7A 00 68 00 2D 00 43 00 4E 00 00 00
Object dump complete.
The program '[0x5B44] cpptest.exe' has exited with code 0 (0x0).
I was using std::codecvt and get a similar problem. I am not sure whether it is a same cause. Just try to provide s possible way to discover the root cause.
You can reference the example in http://www.cplusplus.com/reference/locale/codecvt/in/
It actually "use" the member of mylocale, and it seems without an r-value reference version overload. So when directly write const facet_type& myfacet = std::use_facet<facet_type>(std::locale()); may cause the same problem. .
So try
auto myloc = locale("");
cout.imbue(myloc);
When I run the following code:
#include "gmock/gmock.h"
#include "gtest/gtest.h"
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
int main(int argc, char **argv)
{
::testing::InitGoogleTest(&argc, argv);
_CrtDumpMemoryLeaks();
return 0;
}
I get the following output:
Detected memory leaks!
Dumping objects ->
{652} normal block at 0x00074CE0, 4 bytes long.
Data: < L > 98 4C 07 00
{651} normal block at 0x00074C98, 12 bytes long.
Data: <, > 2C 03 1B 01 00 00 00 00 00 00 00 00
{650} normal block at 0x00074C50, 8 bytes long.
Data: <hI > 68 49 07 00 00 00 00 00
{649} normal block at 0x00074C10, 4 bytes long.
Data: <t > 74 03 1B 01
{648} normal block at 0x00074BC8, 8 bytes long.
Data: <xK > 78 4B 07 00 00 00 00 00
{647} normal block at 0x00074B70, 28 bytes long.
Data: < K L > BC 01 1B 01 01 CD CD CD C8 4B 07 00 E0 4C 07 00
{646} normal block at 0x00074B28, 8 bytes long.
Data: < I > 18 49 07 00 00 00 00 00
{645} normal block at 0x00074AE0, 8 bytes long.
Data: < I > 04 49 07 00 00 00 00 00
{644} normal block at 0x00074A98, 8 bytes long.
Data: < H > DC 48 07 00 00 00 00 00
{643} normal block at 0x00074A50, 8 bytes long.
Data: < H > C8 48 07 00 00 00 00 00
{642} normal block at 0x00074A08, 8 bytes long.
Data: < H > B4 48 07 00 00 00 00 00
{641} normal block at 0x000749C0, 8 bytes long.
Data: < H > A0 48 07 00 00 00 00 00
{640} normal block at 0x00074E90, 1 bytes long.
Data: < > 00
{639} normal block at 0x00074870, 272 bytes long.
Data: < t N > 20 03 1B 01 CD CD CD CD 74 FA 1B 01 90 4E 07 00
{638} normal block at 0x00074F68, 72 bytes long.
Data: <C:\Users\Baz> 43 3A 5C 55 73 65 72 73 5C 45 42 41 52 47 52 49
{637} normal block at 0x00074E48, 8 bytes long.
Data: <hO G > 68 4F 07 00 47 00 00 00
{616} normal block at 0x00074EE0, 72 bytes long.
Data: <C:\Users\Baz> 43 3A 5C 55 73 65 72 73 5C 45 42 41 52 47 52 49
{595} normal block at 0x00074828, 8 bytes long.
Data: < > F0 F9 1B 01 00 00 00 00
{594} normal block at 0x000747E8, 1 bytes long.
Data: < > 00
{561} normal block at 0x000747A0, 5 bytes long.
Data: <fast > 66 61 73 74 00
{496} normal block at 0x00074760, 1 bytes long.
Data: < > 00
{311} normal block at 0x00074720, 1 bytes long.
Data: < > 00
{282} normal block at 0x000746E0, 2 bytes long.
Data: <* > 2A 00
{253} normal block at 0x00074698, 5 bytes long.
Data: <auto > 61 75 74 6F 00
Object dump complete.
What am I doing wrong?
Adding to the accepted answer, the Google documentation states:
Since the statically initialized Google Test singleton requires allocations on the heap, the Visual C++ memory leak detector will report memory leaks at the end of the program run. The easiest way to avoid this is to use the _CrtMemCheckpoint and _CrtMemDumpAllObjectsSince calls to not report any statically initialized heap objects. See MSDN for more details and additional heap check/debug routines.
This involves calling _CrtMemCheckPoint just after ::testing::InitGoogleTest and then calling _CrtMemDumpAllObjectsSince after RUN_ALL_TESTS(). The main function looks a bit like this:
::testing::InitGoogleTest(&argc, &argv);
// Get a checkpoint of the memory after Google Test has been initialized.
_CrtMemState memoryState = {0};
_CrtMemCheckpoint( &memoryState );
int retval = RUN_ALL_TESTS();
// Check for leaks after tests have run
_CrtMemDumpAllObjectsSince( &memoryState );
return retval;
Unfortunately, if a test fails Google test causes a memory leak, which means this isn't a perfect solution.
You're not doing anything wrong. The 'memory leaks' come from heap allocations of the statically initialized google test singleton class.
Here's the answer from google tests FAQ: How do I suppress the memory leak messages on Windows?