Detecting memory leaks when using Boost
I would like to get information about memory leaks with _CRTDBG_MAP_ALLOC, and especially files and line numbers, but I don't get them at the end. I get something like this:
{130} normal block at 0x00695128, 16 bytes. Data: <\ E Pi> 5C A5 45 01 02 00 00 00 01 00 00 00 E8 50 69 00
I saw that this should be before all inclusive:
#define _CRTDBG_MAP_ALLOC
#include <cstdlib>
#include <crtdbg.h>
And some recommend adding this after all the inclusions in all source files:
#ifdef _DEBUG
#define DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif
HOWEVER, in main.cpp, if I explicitly add a memory leak, it shows up with a line number in my output! This is how it works, but not for everything ...
Since I am using librairies Boost, I suspect memory leaks are all happening somewhere in these ... (shared_ptr?). But how do you know where these memory leaks come from?
source to share
Usually _CRTDBG_MAP_ALLOC won't help you with 3rd party code. _CRTDBG_MAP_ALLOC redirects memory allocation functions (i.e. Malloc) to special debug versions that accept file and line numbers (i.e. _malloc___dbg) at compile time. If the third-party code was not built with _CRTDBG_MAP_ALLOC installed, then you will not see this information. Also, it won't help you with non-CRT memory allocation functions (i.e. HeapAlloc, GlobalAlloc, LocalAlloc, VirtualAlloc, etc.), although boosting almost certainly uses CRT functions.
If the allocation number is consistent, you can use _CrtSetBreakAlloc to set a breakpoint when that allocation occurs to see which code is allocating memory. Also, keep in mind that if you call _CrtDumpMemoryLeaks at the end of your program, then all globals will not be destroyed yet, and their memory will be mapped on output.
source to share
Try using _CrtSetAllocHook, which registers callback functions before each heap allocation. A GUI application that uses this to highlight the highlighted highlight line can be found here: Visual Leak Detector
source to share
I would think that \ _CRTDBG_MAP_ALLOC should work with header-only libraries in boost (like shared_ptr) since they are implanted in headers. I highly doubt you will find any memory patches inside shared_ptr. I even doubt that shared_ptr even calls allocates heap memory. Remember that this is very well tested code and chances are you are the one causing the leak.
Since there is no good indication of where the leak is occurring, I assume it is caused by a memory allocation in a third party library and that the library expects you to clean up.
source to share