int main()
{
map<string,string> x;
x["Haitham"]="000#hotmail.com";
x.clear();
_CrtDumpMemoryLeaks();
return 0;
}
when i test for memory leaks for this program the output is Detected
memory leaks!
{152} normal block at 0x0070ABD8, 8 bytes long.
Data: <4 p > 34 AB 70 00 00 00 00 00
{151} normal block at 0x0070AB90, 8 bytes long.
{150} normal block at 0x0070AB08, 72 bytes long.
Data: <p p ` p > 60 A9 70 00 60 A9 70 00 60 A9 70 00 01 00 CD
CD
{145} normal block at 0x00704C40, 8 bytes long.
Data: < ^ > E4 FE 5E 00 00 00 00 00
{144} normal block at 0x0070A960, 72 bytes long.
Data: < p p p > 08 AB 70 00 08 AB 70 00 08 AB 70 00 01 01 CD
CD
Data: < p > 18 AB 70 00 00 00 00 00
Object dump complete.
This issue is that the you're calling the function that checks for memory leaks too soon. The map hasn't been destroyed at the point you call _CrtDumpMemoryLeaks.
Change your code to this:
int main()
{
{
map<string,string> x;
x["Haitham"]="000#hotmail.com";
x.clear();
}
_CrtDumpMemoryLeaks();
return 0;
}
This should now show that the map is destrouyed, since it is local to the { } block.
Related
I'm trying to embed V8 but I have some memory leaks. The following minimal code reproduce the leaks.
int main(int argc, char* argv[])
{
// V8 version 7.1.302.33
v8::V8::InitializeICUDefaultLocation(argv[0]);
v8::V8::InitializeExternalStartupData(argv[0]);
std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();
v8::V8::InitializePlatform(platform.get());
v8::V8::Initialize();
v8::Isolate::CreateParams create_params;
create_params.array_buffer_allocator = v8::ArrayBuffer::Allocator::NewDefaultAllocator();
v8::Isolate* pIsolate = v8::Isolate::New(create_params); // If I remove this line and the next one, memory leak disappears
pIsolate->Dispose();
v8::V8::Dispose();
v8::V8::ShutdownPlatform();
delete create_params.array_buffer_allocator;
}
With this code, my visual studio 2017 print theses leaks in the output
Detected memory leaks!
Dumping objects ->
{5565} normal block at 0x000001BA6F417950, 8 bytes long.
Data: < i > 00 00 E8 69 18 00 00 00
{5564} normal block at 0x000001BA6F416960, 16 bytes long.
Data : <8 >o > 38 D7 3E 6F BA 01 00 00 00 00 00 00 00 00 00 00
{5563} normal block at 0x000001BA6F3ED720, 56 bytes long.
Data: < >o > o > A0 D6 3E 6F BA 01 00 00 A0 D6 3E 6F BA 01 00 00
{989} normal block at 0x000001BA6F4194E0, 128 bytes long.
Data: < >o > o > A0 D6 3E 6F BA 01 00 00 A0 D6 3E 6F BA 01 00 00
{988} normal block at 0x000001BA6F416CD0, 16 bytes long.
Data: < p ` > 70 B4 60 0A FF 7F 00 00 00 00 00 00 00 00 00 00
{987} normal block at 0x000001BA6F417270, 16 bytes long.
Data : < X ` > 58 B4 60 0A FF 7F 00 00 00 00 00 00 00 00 00 00
{986} normal block at 0x000001BA6F3ED6A0, 56 bytes long.
Data : < >o > o > 20 D7 3E 6F BA 01 00 00 20 D7 3E 6F BA 01 00 00
Object dump complete.
So do you know what I forget ?
Thanks in advance for your help ;)
I copied your code, and ran it on linux environment, with -fsanitize=address flag setted, didn't get any memory leak error.
Here a dirty workaround to remove most memory leaks.
You have to redefine the internal class IsolateAllocator to call private function FreeProcessWidePtrComprCageForTesting().
A first way by adding a new function Free() to be able to call the private function.
namespace v8::internal
{
class IsolateAllocator
{
public:
static void Free() { FreeProcessWidePtrComprCageForTesting(); }
private:
static void FreeProcessWidePtrComprCageForTesting();
};
} // namespace v8::internal
or without adding a function to IsolateAllocator, but using a friend class like it's done in v8 unit test (I just rename the friend class).
namespace v8::internal
{
class IsolateAllocator
{
private:
friend class SequentialUnmapperTest;
static void FreeProcessWidePtrComprCageForTesting();
};
class SequentialUnmapperTest
{
public:
static void Free() { IsolateAllocator::FreeProcessWidePtrComprCageForTesting(); }
};
} // namespace v8::internal
Call the Free() function before v8::V8::Dispose();:
isolate->Dispose();
v8::internal::IsolateAllocator::Free();
v8::V8::Dispose();
v8::V8::ShutdownPlatform();
delete create_params.array_buffer_allocator;
There is still few memory leak due to call v8::V8::InitializeICUDefaultLocation() (which do some allocation using when calling udata_setCommonData()) and other due to base::LazyInstance<std::weak_ptr<CodeRange>>::type process_wide_code_range_ in code-range.cc which store a std::weak_ptr<> which is never destroyed...
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 have client/server app. Interaction implemented via Boost.Asio.
I created unit test to check long running transmission of data.
During the test memory leak detected.
Task Manager shows me that memory usage constantly grows - up to 35MB per 10min. Report produced at the end of test contains this:
Result StandardError: Detected memory leaks!
Dumping objects ->
{14522} normal block at 0x00E8ADC0, 16 bytes long.
Data: < _M} Y > B0 5F 4D 7D F9 59 F2 02 F4 E9 E6 00 CC CC CC CC
{14012} normal block at 0x00E8B280, 16 bytes long.
Data: < v > C0 76 A4 00 94 01 00 00 98 01 00 00 F0 D2 E3 00
{14011} normal block at 0x00E74B38, 12 bytes long.
Data: < > 00 00 00 00 9C 01 00 00 98 01 00 00
{14007} normal block at 0x00E745F8, 8 bytes long.
Data: < L > E0 4C E5 00 00 00 00 00
{14006} normal block at 0x00E54CB8, 60 bytes long.
Data: < v 4 > E4 76 A4 00 D0 D3 B0 00 00 00 00 00 34 80 E3 00
{13724} normal block at 0x00E710F8, 385 bytes long.
Data: < > 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{13722} normal block at 0x00E85C58, 28 bytes long.
Data: < F _ _ > F2 B6 46 00 B4 5F E3 00 A0 5F E3 00 BC 96 E7 00
{13720} normal block at 0x00E6F9B8, 80 bytes long.
Data: <wxF > 77 78 46 00 FC FF FF FF 00 00 00 00 CC CC CC CC
{13700} normal block at 0x00E6DFD0, 88 bytes long.
Data: < > C8 A4 A4 00 01 00 00 00 01 00 00 00 00 00 00 00
…
Data: <` X L > 60 8E E0 00 58 17 E2 00 CD 4C F7 EA
{153} normal block at 0x00DF0070, 12 bytes long.
Data: <` kf > 60 8D E0 00 98 00 E2 00 15 6B 66 0E
{151} normal block at 0x00DF0038, 12 bytes long.
Data: < .g> 20 86 E0 00 E0 FC E1 00 9D B7 2E 67
{149} normal block at 0x00DF0658, 12 bytes long.
Data: < G > A0 89 E0 00 00 00 00 00 47 01 D5 11
{147} normal block at 0x00DF0268, 12 bytes long.
Data: <` > 60 84 E0 00 A8 F5 E1 00 ED 8C AA BA
{145} normal block at 0x00DF0230, 12 bytes long.
Data: < ' " > 20 84 E0 00 00 11 E2 00 27 B0 22 00
{143} normal block at 0x00DF0690, 12 bytes long.
Data: <` P KnOQ> 60 88 E0 00 50 04 E2 00 4B 6E 4F 51
{141} normal block at 0x00DF0540, 12 bytes long.
Data: <` > 7> 60 82 E0 00 00 0A E2 00 3E 0D 9E 37
{139} normal block at 0x00DF0620, 12 bytes long.
Data: <Pq 1 > 50 71 DF 00 00 00 00 00 E5 DD 31 B5
{137} normal block at 0x00DF0700, 12 bytes long.
Data: < q # #> 10 71 DF 00 40 FA E1 00 14 8B 0D 23
{134} normal block at 0x00DF5CE0, 96 bytes long.
Data: <h BV BV > 68 19 E0 00 D0 42 56 00 E0 42 56 00 88 00 00 00
{133} normal block at 0x00DF0188, 8 bytes long.
Data: < \ > A0 5C DF 00 00 00 00 00
{132} normal block at 0x00DF5CA0, 16 bytes long.
Data: < > 88 01 DF 00 D8 AA DF 00 20 AC DF 00 20 AC DF 00
Object dump complete.
I tried to put breakpoint to mentioned memory allocations via boost's --detect_memory_leaks="allocation number" and setting in Watch window at Debug mode _crtBreakAlloc = 1000. It does not work. Maybe because leaks occur not in my code, but in boost/OpenSSL code?
I can't figure out where leaks occur. What can I do?
Windows 8, Visual Studio 2015, boost 1.60, OpenSSL 1.0.2g
Have a look at this post to see some suggested tips for dealing with memory leaks under windows. Have a scroll down, don't just look at the first answer. In particular it may be worth considering the DEBUG_NEW macro-based solution discussed by the second answer. Given that boost asio is largely header-only, this should help you even if the offending allocations come from the boost library.
Part 1: Report from Visual Studio about memory leaks
I'm using Boost.Asio to communicate with the server over TLS, i.e. Boost.Asio uses OpenSSL.
Seems that OpenSSL initializes itself and do not cleans memory before the end of the app (because app closes and memory will be released anyway).
This is not big chunk of memory (I do not know how to measure it).
As result Visual Studio treated that memory as leak. But it is not.
(This is my assumption, maybe real reason for such report is smth else. But I do not see any other possible reasons. )
Part 2:
In the question above I asked about memory leak for tens of Mb. This is my bad code that leads to huge memory buffer )).
Huge memory consumption and report from VisualStudio about memory leak made me believe that smth is very wrong ))
Buffer easily reduced to much smaller size.
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?