C / C++ / MFC

2-May-02 5:25

hrm.

i have about 8 different memory leaks, and i can't seem to track em down.. so i have some questions..

1) do memory leaks only occur when the 'new' keyword is used to create a pointer, and that pointer is never deleted (using 'delete' keyword)?

2) if my memory leaks say 'CObject' is there any way to tell what class it is?

i am using several classes i derived from CObject, and i use CObArray quite alot too.. i know that after im done with a CObArray that i have to loop through it and delete all the objects, and im doing this everywhere..

any help in general would be great.. i don't want to have any memory leaks..

thanks!

-dz

Ravi Bhavnani2-May-02 5:29

2-May-02 5:29

dazinith wrote:
do memory leaks only occur when the 'new' keyword is used to create a pointer
You can also get memory leaks when you create GDI objects such as pens and brushes and forget to unselect them out of the DC and delete them.

dazinith wrote:
i know that after im done with a CObArray that i have to loop through it and delete all the objects,
Perhaps you're forgetting to do a RemoveAll() after you delete the individual objects?

/ravi

"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com

Tom Archer2-May-02 5:37

2-May-02 5:37

Actually, you do not need to remove items from an array once they've been deleted. I do it as a sanity check so that after the delete loop I can assert if any items remain in the array. However, once you've deleted the actual item in memory, the array simply points to an invalid item for which no memory is still allocated.

Cheers,
Tom Archer
Author, Inside C#

A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

Ravi Bhavnani2-May-02 5:45

2-May-02 5:45

Ah. Looks like CObArray's destructor cleans up after itself. Thanks for the tip!

/ravi

"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com

Tom Archer2-May-02 5:55

2-May-02 5:55

No problem. I've actually spent so much time in the guts of MFC that I've often thought of writing a second edtion of the MFC Internals book. Do you think such a book would sell? I think it would. I think there are stil enough people new to MFC that would get a tremendous amount out of a book that explains how their apps are working internally. The thing that I would add to such a book, however, is a section at the end of each chapter that basically says "Ok. You know how this bit works internally. Here's where you can apply this knowledge". I think that would make the book more practical instead of coming off as just trivia. What do you think?+

Cheers,
Tom Archer
Author, Inside C#

A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

Ravi Bhavnani2-May-02 6:05

2-May-02 6:05

Tom, I for one would welcome (more) info on MFC's internals. And as you pointed out, real-world usage examples would come in *very* handy.

/ravi

"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com

Paresh Solanki2-May-02 6:43

Paresh Solanki

2-May-02 6:43

Sounds like a good idea.

There's a couple of people here (including me) who'd like to know more about MFC and how to apply it.

A problem I have is that I know what I want a program to do, but not how to achieve that in a windows environment. CP has helped a lot, but sometimes a book of 'typical' applications would help too

Paresh Solanki
There is no substitute for genuine lack of preparation.

Tom Archer2-May-02 5:42

2-May-02 5:42

dazinith wrote:
any help in general would be great.. i don't want to have any memory leaks..

Always a worthy goal Smile | :)

The way to track down memory leaks in an MFC application - short of spending hours and hours manually tracking down and tracing on every new and delete operation - is to use the CMemoryState class. There are actually several ways to use this class so instead of me enumerating them all, I'll just point you to the article entitled "Taking Memory Snapshots" in your MSDN online help.

Good luck! Everybody hates those *#*& things!

Cheers,
Tom Archer
Author, Inside C#

A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

Niklas L2-May-02 5:44

Niklas L

2-May-02 5:44

Make sure you have no code that looks like

CObArray vec;
for (int i = 0; i < vec.GetSize(); i++)
{
	delete vec[i];
	vec.RemoveAt(i);
}

where just every other element is deleted. This one I've seen lots of times.

dazinith2-May-02 5:51

2-May-02 5:51

my deleting of CObArray's looks like this

// delete all items in the text list
if (m_oaText->GetSize() > 0)
do
{
CTextPrintObject* pObj = (CTextPrintObject*)m_oaText->GetAt(0);
delete pObj;
m_oaText->RemoveAt(0);
} while (m_oaText->GetSize() > 0);

m_oaText->RemoveAll();
delete m_oaText;

does this look right?

-dz

Niklas L2-May-02 6:00

Niklas L

2-May-02 6:00

Sure looks functional enough. (Even though quite inefficient calling RemoveAt(0), since the array has to do a copy of all remaining items for each turn in the loop. Maybe you should consider looping backwards.)
Does you CTextPrintObject allocate any memory, not deleted in it's destructor?

Ravi Bhavnani2-May-02 6:03

2-May-02 6:03

After having read Tom's post, I think I'd write this as:

for (long nIndex=0; (nIndex < m_oaText->GetSize()); nIndex++) {
    CTextPrintObject* pObj = (CTextPrintObject*) m_oaText->GetAt(nIndex);
    ASSERT (pObj != NULL);
    delete pObj;
    m_oaText->SetAt (nIndex, NULL);  // good coding hygiene
}
delete m_oaText;

/ravi

"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com

dazinith2-May-02 6:05

2-May-02 6:05

welp i think i found where the leak is.. but i don't know whats wrong with the code.. if i comment out this chunk of code i only get 1 memory leak.. if i dont comment it out i get 8.. anyone have any suggestions as to whats wrong with this? basicly im just setting dates for a couple date pickers..

//Setup the date picker
m_cdPeriodEnd.SetFormat(_T("MM/dd/yyyy")); // force short date format to MM/dd/yyyy
m_cdPeriodBegin.SetFormat(_T("MM/dd/yyyy"));
COleDateTime dtMin(2002,7,31,0,0,0); // set the minimum date which can be chosen
COleDateTime dtMax(2003,6,30,0,0,0); // set the maximum date which can be chosen

// verify the min and max dates are valid, then set the range for the date picker
if ((dtMin.GetStatus() == COleDateTime::valid) && (dtMax.GetStatus() == COleDateTime::valid))
{
m_cdPeriodEnd.SetRange(&dtMin,&dtMax);
m_cdPeriodBegin.SetRange(&dtMin,&dtMax);
}
else
{
if (dtMin.GetStatus() != COleDateTime::valid)
AfxMessageBox("This program has attempted to set an invalid minimum date for selection.");
if (dtMax.GetStatus() != COleDateTime::valid)
AfxMessageBox("This program has attempted to set an invalid maximum date for selection.");
CDialog::EndDialog(IDABORT);
}

-dz

dazinith2-May-02 6:20

Re: The VC++ way to point out memory leak for you!

2-May-02 6:20

hrm.. nevermind i don't think thats it.. i think i should be able to track it down, thanks for the advice, and thanks for letting me know about deleting brushes too!

thanks! Smile | :)

-dz

Maxwell Chen2-May-02 7:04

Maxwell Chen

2-May-02 7:04

Try this console code, it demonstrates C Runtime Library on memory leak detection.

#include <iostreamᡊe9ac73-238b-46be-991d-0f050c37248d#include <crtdbg.hᡊe9ac73-238b-46be-991d-0f050c37248d
using namespace std;


void main()
{
	_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF | _CRTDBG_ALLOC_MEM_DF);

	_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE);
	_CrtSetReportFile(_CRT_WARN, _CRTDBG_FILE_STDOUT);

	int* p = new int;

	*p = 4;

	p = 0;
	delete p;
}

Maxwell Chen
No code is good code.

Re: The VC++ way to point out memory leak for you!

Anders Molin2-May-02 8:45

Anders Molin

2-May-02 8:45

and if you defines #define _CRTDBG_MAP_ALLOC before any includes, you also get the line where you allocated the (not free'd) memory...

- Anders

Money talks, but all mine ever says is "Goodbye!"

Re: The VC++ way to point out memory leak for you!

Maxwell Chen2-May-02 17:10

Maxwell Chen

2-May-02 17:10

But when I applied those functions

_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF | _CRTDBG_ALLOC_MEM_DF);
_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE);
_CrtSetReportFile(_CRT_WARN, _CRTDBG_FILE_STDOUT);

in MFC app projects, set the debug argument to redirect the report to some txt file like MemLkRpt.txt , nothing's reported in that file. How should I do, like: when should these _CrtSet???( ) functions be called, in the ctor of theApp, or some other where? Any additional steps must be taken? ... etc.

And by the way, I can not delete the generated MemLkRpt.txt file!

Thanks Smile | :)

Maxwell Chen
No code is good code.

Roger Allen2-May-02 23:24

Roger Allen

2-May-02 23:24

Serialization can also give memory leaks. If your not 100% sure about whats going on.

If you have an object that can be created dynamically from serialization you could do this:

CMyObject *pObject = new CMyObject ;

ar >> pObject ;   // read the object (leak) (the pointer value changes)

... stuff

delete pObject ;

The problem here is that your newed object is lost as the serialization code allocates another object itself dynamically.

Roger Allen
Sonork 100.10016

If I had a quote, it would be a very good one.

#if directive

_Magnus_2-May-02 5:06

_Magnus_

2-May-02 5:06

I want to set up an #if condition based on a environment variable,
anyone know if it's possible to set up such a thing?
(I'm using VC6)

/Magnus

Re: #if directive

Tom Archer2-May-02 5:11

2-May-02 5:11

I don't believe so. Retrieving an environment variable would entail running code. The #if is a preprocessor directive that is resolved at compile-time, before your code runs.

Cheers,
Tom Archer
Author, Inside C#

A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

Re: #if directive

_Magnus_2-May-02 5:24

_Magnus_

2-May-02 5:24

Yes, that i am aware of, i tought maybe someone knew of some wierd
#pragma directive or similar that did the trick.

Looks like i have to do some .bat file that runs nmake.
(Back to the 80's Smile | :)

)

/Magnus

Re: #if directive

Tom Archer2-May-02 5:35