How to disable Memory leak detector in Visual C 2010 ?

[kalenko]

Hi every body,
My visual studio VC IDE 2010 has enabled Memory leak detector by default (I find it in Output window). But I wonder whether it is enabled by default or by someone else. So my question is:
1. Does VC 2010 enabled Memory leak detector by default ?
2. How to disable Memory leak detector and enable it again ? (I would like to practice by myself).
Thank you.

[modoran]

Compile the application in release mode :)

[andywestken]

If the leak reports are coming from the debug version of the CRT, it does sound like something might have turned on the automatic call to _CrtDumpMemoryLeaks on exit. This flag (_CRTDBG_LEAK_CHECK_DF) is supposedly turned off by default. (Are you using MFC?)

You can use _CrtSetDbgFlag to turn this flag off (and back on). See MSDN entry on _CrtSetDbgFlag for more info.

Andy

[kalenko]

Hi Andy,
I have never turned on this flag since I installed visual studio. But the Output window always shows the leak reports whenever I do not free the heap.
Now I use the Visual leak detector, there are two different leak reports. One says detected memory leak, the other says no memory leak detected. Here is the output:

'Capture.exe': Unloaded 'C:\Windows\System32\igdumd32.dll'
'Capture.exe': Unloaded 'C:\Windows\System32\igdumdx32.dll'
'Capture.exe': Unloaded 'C:\Windows\System32\dxva2.dll'
The thread 'Win32 Thread' (0xedc) has exited with code 0 (0x0).
No memory leaks detected.
'Capture.exe': Unloaded 'C:\Windows\System32\dbghelp.dll'
Visual Leak Detector is now exiting.
Detected memory leaks!
Dumping objects ->
{134} normal block at 0x00464A88, 29 bytes long.
Data: < JF JF > 00 00 00 00 98 4A 46 00 9F 4A 46 00 00 00 00 00
{133} normal block at 0x00464A10, 57 bytes long.
Data: < ( IF > 00 00 00 00 28 00 00 00 00 00 00 00 98 49 46 00
{132} normal block at 0x00464998, 54 bytes long.
Data: < ( JF IF > 00 00 00 00 28 00 00 00 10 4A 46 00 20 49 46 00
{131} normal block at 0x00464920, 53 bytes long.
Data: < ( IF HF > 00 00 00 00 28 00 00 00 98 49 46 00 A0 48 46 00
{130} normal block at 0x004648A0, 61 bytes long.
Data: < ( IF (HF > 00 00 00 00 28 00 00 00 20 49 46 00 28 48 46 00
{129} normal block at 0x00464828, 53 bytes long.
Data: < ( HF GF > 00 00 00 00 28 00 00 00 A0 48 46 00 A8 47 46 00
{128} normal block at 0x004647A8, 61 bytes long.
Data: < ( (HF 0GF > 00 00 00 00 28 00 00 00 28 48 46 00 30 47 46 00
{127} normal block at 0x00464730, 56 bytes long.
Data: < ( GF > 00 00 00 00 28 00 00 00 A8 47 46 00 00 00 00 00
Object dump complete.
The program '[3484] Capture.exe: Native' has exited with code 2 (0x2).

Please tell me what happens ?
Thank you

[modoran]

Why do you use a tool like Visual Leak Detector and them complain on a forum that is actually working as it should ? Lol ...........

Use VLDDisable () function to disable it at runtime.
http://vld.codeplex.com/wikipage?title=Controlling%20Leak%20Detection%20at%20Runtime&referringTitle=Documentation

[kbw]

Have you considered fixing the memory leaks?

[kalenko]

@kbw: Yes, I have

I check my code and found nothing which could produce memory leak. So I think that the VLD report would be correct, and the report of the CRT debug (I could not turn it off) would be wrong.

[kbw]

The memory leak is quite easy to find. Let's take one of them.

{134} normal block at 0x00464A88, 29 bytes long.
Data: < JF JF > 00 00 00 00 98 4A 46 00 9F 4A 46 00 00 00 00 00

Run the program a few times and confirm that it's always allocation 134. Then add this at the start of your program:

_CrtSetBreakAlloc(134);

Run your program in the debugger. The program will stop just before it makes the allocation that's leaking. You can then look at the call stack to see who called malloc, and fix the leak.

[kalenko]

@kbw: I try to put break point but the application never stop at any break point. I wonder why the VLD says that: No memory leaks detected ! (as the Output window I post before.)

[andywestken]

The same o/p format is used by CRT's built in leak detection code, so VLD isn't necessarily about.

You could try #defining _CRTDBG_MAP_ALLOC. It this is used correctly, the leak report will include the file name and line number where the allocation was made.

If you linking to the DLL version of the CRT, then string memory pooling, etc can result it "leaks".

Andy

[kbw]

I try to put break point but the application never stop at any break point.

The reason is pretty obvious, allocation 134 has past before _CrtSetBreakAlloc(134); was executed.

You really need to have it executed very early on. Perhaps you have global objects that are allocating memory and being constructed before running main. I'm not sure what your program looks like, but the principle is sound, so please take another look.

[kalenko]

I am using MFC, and I put break point as below:

CCaptureApp::CCaptureApp()
{
	// support Restart Manager
	m_dwRestartManagerSupportFlags = AFX_RESTART_MANAGER_SUPPORT_RESTART;
	// TODO: add construction code here,
	// Place all significant initialization in InitInstance
	_CrtSetBreakAlloc(134);
}

Is it alright ? or Do I have to put at other location ?

[kbw]

That's usually ok, but you might catch it earlier by declaring a global class, something like:

namespace
{
    class C
    {
    public:
        C() { _CrtBreakAlloc(134); }
    };
    C c;
}

[kalenko]

@kbw: The application still does not stop at any break point. I think that the CRT debug report is wrong.

[kbw]

It could be wrong. It's possible for the heap checker to miss global objects that are released after the heap check is run.

How far you go with this depends on how determined you are to get to the bottom of this, but as you said, it may not real leak after all.

Here's one final thing you can do.
1. Add a call to malloc (or new) in your program and step into it in the debugger.
2. You'll eventually hit a function, _heap_alloc_dbg_impl(), which performs the allocation.
3. Step a few lines in and you'll hit a statement:

lRequest = _lRequestCurr;

4. Step past it and set a break point.
5. Stop the program.
6. Run the program in the debugger.

The program will stop at the allocation. The call stack window will show who's requested the allocation. The autos window woll show the allocation number. Hit Run to step to the next allocation. This way, you'll see them all, the startup code, global objects, ... everything.

[kalenko]

I find the value of lRequest and _lRequestCurr in Autos window, but what does this value means ?

[kalenko]

@kbw:
Here is the Autos window:

_crtBreakAlloc -1 long
_lRequestCurr 134 long
lRequest 134 long

And here is the Call Stack window:

> msvcr100d.dll!_heap_alloc_dbg_impl(unsigned int nSize, int nBlockUse, const char * szFileName, int nLine, int * errno_tmp) Line 392 C++
msvcr100d.dll!_nh_malloc_dbg_impl(unsigned int nSize, int nhFlag, int nBlockUse, const char * szFileName, int nLine, int * errno_tmp) Line 239 + 0x19 bytes C++
msvcr100d.dll!_nh_malloc_dbg(unsigned int nSize, int nhFlag, int nBlockUse, const char * szFileName, int nLine) Line 302 + 0x1d bytes C++
msvcr100d.dll!malloc(unsigned int nSize) Line 56 + 0x15 bytes C++
opencv_core242d.dll!575f6fc0()
[Frames below may be incorrect and/or missing, no symbols loaded for opencv_core242d.dll]
opencv_core242d.dll!575f6ca7()
opencv_core242d.dll!5763e2a2()
msvcr100d.dll!_initterm(void (void)* * pfbegin, void (void)* * pfend) Line 873 C
opencv_core242d.dll!57607e93()
ntdll.dll!7764515c()
ntdll.dll!77627d9b()
ntdll.dll!77627d16()
opencv_core242d.dll!576080e1()
ntdll.dll!7765af24()
ntdll.dll!7765fd2e()
ntdll.dll!7766165f()
ntdll.dll!776690be()
ntdll.dll!7765b2c5()

Could it imply that the leaks are caused by OpenCV library ?

[kbw]

The leaked memory is allocated by OpenCV.

Perhaps you've initialised the library, but not uninitialised it. Or maybe it genuinely does leak a few blocks. I'm not familiar with OpenCV, so I can't comment further.

[kalenko]

I have found the statement which produce memory leaks. Here is a small program which generates the same memory leaks as my application do:

#include <opencv2\opencv.hpp>
#include <opencv2\highgui\highgui.hpp>

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

#ifdef _DEBUG   
	#ifndef DBG_NEW      
		#define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )      
		#define new DBG_NEW   
#endif
#endif  // _DEBUG
class C
{
public: 
		C();
		~C();
		void Test();
};
void C::Test()
{
	IplImage * image = cvCreateImage(cvSize(640, 480), 8, 3);
	cvReleaseImage(&image);
	image = NULL;
}
int main(int argc, char** argv)
{
	_CrtDumpMemoryLeaks();
}

And here is the Output window:

'CVSample.exe': Loaded 'C:\Windows\System32\msctf.dll', Cannot find or open the PDB file
Detected memory leaks!
Dumping objects ->
{135} normal block at 0x00454B18, 29 bytes long.
Data: < (KE /KE > 00 00 00 00 28 4B 45 00 2F 4B 45 00 00 00 00 00
{134} normal block at 0x00454AA0, 57 bytes long.
Data: < ( (JE > 00 00 00 00 28 00 00 00 00 00 00 00 28 4A 45 00
{133} normal block at 0x00454A28, 54 bytes long.
Data: < ( JE IE > 00 00 00 00 28 00 00 00 A0 4A 45 00 B0 49 45 00
{132} normal block at 0x004549B0, 53 bytes long.
Data: < ( (JE 0IE > 00 00 00 00 28 00 00 00 28 4A 45 00 30 49 45 00
{131} normal block at 0x00454930, 61 bytes long.
Data: < ( IE HE > 00 00 00 00 28 00 00 00 B0 49 45 00 B8 48 45 00
{130} normal block at 0x004548B8, 53 bytes long.
Data: < ( 0IE 8HE > 00 00 00 00 28 00 00 00 30 49 45 00 38 48 45 00
{129} normal block at 0x00454838, 61 bytes long.
Data: < ( HE GE > 00 00 00 00 28 00 00 00 B8 48 45 00 C0 47 45 00
{128} normal block at 0x004547C0, 56 bytes long.
Data: < ( 8HE > 00 00 00 00 28 00 00 00 38 48 45 00 00 00 00 00
Object dump complete.
The program '[2620] CVSample.exe: Native' has exited with code 0 (0x0).

I do not know why ? Can anyone help me ? (I am using OpenCV 2.42)

[kbw]

Does the C++ of OpenCV leak?