I just spent an hour or two tracking down the last 16-byte memory leak in a project that I was working on. What it turned out to be was actually something\u00a0EXPLICITLY\u00a0cited in the Microsoft reference manual as having been fixed. \u00a0Yet it turned out not to be.<\/p>\n
I had finished instrumenting my program for CRT memory reporting. CRT memory leak reporting is normally very handy as it tells you exactly what lines of code are the source of the leak, how many bytes, and dumps the data that’s leaking. All it requires is that you instrument your headers as described\u00a0here\u00a0<\/a><http:\/\/msdn.microsoft.com\/en-us\/library\/x98tx3cf.aspx<\/a>><\/p>\n With all this done you can run the program and then see the results of the report in the Visual studio output window when the program exits:<\/p>\n If you use the _CrtSetBreakAlloc() with the allocation number (<\/span>{18}<\/span>in this case), when the program starts up in debug mode the debugger will automatically stop on that allocation. You can then look at the call stack and get a great idea of whats leaking and why. Overall, it’s very handy and helped me track down all my leaks.<\/span><\/p>\n Well, the problem\u00a0was that I fixed all the leaks but 2 in my particular program. \u00a0I reduced the code down until I was down to just main() that dumped the memory report and exited. \u00a0 The problem was that it STILL reported a\u00a0leak! I added a fake leak, and the very\u00a0first allocation (that was leaking) in the program had a higher allocation number than the allocations that were supposedly leaking. \u00a0This implied quite strongly that the leak is happening BEFORE I actually even get into the program. How is that possible?<\/p>\n Well, there are a few things that get allocated for you before your program starts. Fixed-sized arrays, (int array[10];) string literals, and static variables are all objects are allocated on the stack (as opposed to the heap) are usually allocated at load time. When I looked at all the static allocations in my program, I saw this:<\/p>\n Do you see any problem? \u00a0I didn’t – at first. The problem is that std::string is a STL object that has a constructor. \u00a0Statics are usually allocated at load time. Which means their constructors are likely being called during load time BEFORE the main() is hit. We assume\u00a0that the corresponding destructors are called after main exits. Apparently, the CRT memory tracking starts right as the program starts but\u00a0is supposed to ignore any CRT allocations (ones made by the standard C libraries). \u00a0Apparently these static allocations by STL objects are captured. \u00a0Since we report leaks BEFORE we hit the program exit, we haven’t actually hit those ‘hidden’\u00a0destructors for those static strings yet. \u00a0Those allocations are still reported as active – and hence ‘leaked’. \u00a0I only caught this because I’d initialized those strings with string literals. \u00a0The leak dumped the memory and I recognized the strings. So a good way to test if this is happening to you is\u00a0set your object data\u00a0to something unique and make sure those unique values appear in\u00a0the leak report memory dump.<\/p>\n Yet another clue is that the value of an uninitialized string consists of a number that appears to be a memory address (while the addresses change each run, other allocations in that run have roughly the same addresses), and a bunch of zeros. This likely corresponds to a pointer to the character buffer, and an int that indicates size. This is further confirmed by the fact the leaks are 8 bytes each in x86 build, and 16 bytes on a x64 build. This corresponds to the sizeof(int)+sizeof(void*) sizes on the respective builds.<\/p>\n Solution: Links:<\/strong>\/\/ this goes before ANY other includes in ALL your headers\r\n#define _CRTDBG_MAP_ALLOC\r\n#include <blah>\r\n#include <blah>\r\n...\r\n
<\/code>main()\r\n{\r\n _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); \/\/ tells leak detector to dump report at any program exit\r\n _CrtSetBreakAlloc(18); \/\/ set breakpoint on a specific allocation number\r\n}\r\n<\/code><\/pre>\nDetected memory leaks!\r\nDumping objects ->\r\nC:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18}\r\nnormal block at 0x00780E80, 64 bytes long.\r\nData: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD\r\nObject dump complete.\r\n<\/pre>\nclass Bar\r\n{\r\n ...\r\nprivate:\r\n static std::string m_name;\r\n static std::string m_value;\r\n}\r\n<\/pre>\n
\n<\/strong>The solution is to ignore what is (likely) a false report, or change the static std::string objects to non-static or static std::string* pointers. Then make an appropriate initializer\/destructor that creates\/destroys\u00a0those string objects. This means the memory is allocated\/deallocated on the heap\u00a0in the scope of the program run. The other thing you do is file a bug with Microsoft and put a few comments on the documentation\u00a0website that indicates the statics are still leaking and they haven’t really fixed it yet. \ud83d\ude42<\/p>\n
\nMS article about CRT memory debug operations that says this bug had been fixed (but it has not as of VS2012)<\/p>\n