Threads, DLL and MFC

[Miramar Misiones]

Hi, I have a small MFC app, i have two buttons, i have a dummy function too.
I have a small dll, the issue is when i press the button 2 I have memory leak (i have tried with CMemoryState and does not detect any memory leak, but i can see it in the Process Explorer).

In my simple dll code i have in the "stdafx.h" file the following line
#include <afxwin.h>,
but if i comment this line, the memory leak is gone.

I tried to comment all my dll code (except that include) and the problem still persists.

Any clues of this behavior?

(I tried in a Win32 application instead of MFC and i have the same problem)


void CPruebaThreadDlg::OnBnClickedButton1()
{
LPVOID lpParam = NULL;

AfxBeginThread(dummy, lpParam, THREAD_PRIORITY_NORMAL, 0, 0, NULL);
}

void CPruebaThreadDlg::OnBnClickedButton2()
{
int i;
HMODULE hmod = LoadLibrary("SimpleDll.dll");
while(true)
{
for(i = 0; i <= 150; i++)
OnBnClickedButton1();
Sleep(700);
}
}

UINT dummy(LPVOID)
{
return 0;
}

[MrViggy]

Why do you think you have a memory leak? Often, when a program release memory, the OS will show that it is still "allocated" to the application. Something like a cache, so that if your app immediately requests some memory, the OS already has it marked to your app (and it can provide it quicker).

The most accurate way to test for memory leaks is to use some kind of memory profiler (like Rational Purify).

Viggy

[Miramar Misiones]

Thanks for your answer,
I considered your suggestion and i run this program for 24 hours and the memory usage increased consideribly (1000% at least).

but if i comment the "#include " line in my dll code, the memory increases a little and then it is freed again (I use the process explorer)

[MrViggy]

Well, all I can say is that the code you posted has no visible memory leaks. Run a memory profiler. Explorer is not accurate.

Also, try this. Run your program, then minimize it. See if your memory goes down. If so, you do not have a memory leak.

Viggy

[Miramar Misiones]

I run perfmon which confirmed me that the private bytes of my process increases a lot.

If i minimize the window, the memory goes down (i would have to do some minor changes on my code to let me minimize the window)

I run rational purify who shows me no memory leak, but if my process starts with 4MB ten hours later i have 30MB.

If i change my code in order to stop invoking OnBnClickedButton1() after a minutes, the amount of memory does not goes down, and when I restart to invoke the function again, the memory goes up again.

I agree with you that the process SHOULD NOT have memory leaks, but in a few hours the memory increases a lot, and the OS never frees it, unless in my dll code i comment #include <afxwin.h>. But i have others dll, without that include and the problems still persists.

What do you suggest in order to ensure that my process does not have memory leaks?

Thanks a lot for your answers

[MrViggy]

If Rational Purify says there are no leaks, you can be reasonably sure you have no leaks. The fact that the memory goes down after minimizing the app means that your application does not have that memory in use.

Like I said, it is the operating system that is "holding" the memory for you, in case you request more memory. It's not a problem, as a matter of fact, this is the way it works.

Viggy

[Miramar Misiones]

OK, i agree with you, but i want to be absolutely sure

Thanks a lot for your help

[Miramar Misiones]

Excuse my english,

I agree with you, i wanted to be sure so i asked you, now i am sure.

Thanks

[DSSD]

In your function CPruebaThreadDlg::OnBnClickedButton2() you call LoadLibraray. You forgot to call FreeLibrary. This leads to a Handle leak and possibly also to memory leak.

[Miramar Misiones]

I can´t call FreeLibrary because if i free the library and load again i lost the state of some variables.

[MrViggy]

In your function CPruebaThreadDlg::OnBnClickedButton2() you call LoadLibraray. You forgot to call FreeLibrary. This leads to a Handle leak and possibly also to memory leak.
Nope, it's not. If you call LoadLibrary, and the module is already loaded, you will get the same handle that was originally returned. However, what will happen is that the module's reference count will be incremented.

A better style of coding might be to make the handle to the DLL a member variable of the dialog. Call "LoadLibrary" once (maybe in the CTOR), and "FreeLibary" once (maybe in the DTOR).

Viggy