C / C++ / MFC

11-Feb-04 2:15

Hello guys,

during debugging the compiler gives this memory leak warning messages. Due to my lack of knowledge, I am not able to find which lines (parts) of the codes causing the memory leak, by telling from the messages.

Detected memory leaks!
Dumping objects ->
{161} normal block at 0x00C86988, 25 bytes long.
 Data: <` l             > 60 C0 6C 00 08 00 00 00 08 00 00 00 01 00 00 00 
{84} normal block at 0x00C867A0, 51 bytes long.
 Data: <` l "   "       > 60 C0 6C 00 22 00 00 00 22 00 00 00 01 00 00 00 
{78} normal block at 0x00C86618, 40 bytes long.
 Data: <g               > 67 00 00 00 D3 01 00 00 00 00 00 00 00 00 00 00 
Object dump complete.

Can anyone help?

Antti Keskinen11-Feb-04 2:31

11-Feb-04 2:31

The memory leaks are pretty small by size, this suggests that the unfreed objects are some small or tiny variables. Try double-checking your source files that for each memory reserving call (new or malloc) you call the respective deletion call (delete or free).

The final option is to run the debugger, copy each new reserved memory's pointer's target address into paper and then compare these with the posted object addresses. This is tedious and long-term work but allows you to pinpoint what pointers are not freed properly.

Remember that the most common cause for these problems is that you have an object that reserves memory dynamically in it's constructor, but does not free it in the destructor or during it's life cycle. Once again, check your code.

Alternatively, if you have money to spare, try investing into some memory-validation program, which are available through CodeProject partners as well. There are many available, and they don't even cost too much.

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.

J.B.11-Feb-04 5:21

11-Feb-04 5:21

Thanks for the help, Antti

I've been looking hard into my code for any suspicious memory reserving calls, so far I have failed to find anything.

Antti Keskinen wrote:
Try double-checking your source files that for each memory reserving call (new or malloc) you call the respective deletion call (delete or free).

I guess my difficulty is that I have not manually made any new or malloc in the program. All the possible memory allocating pointer calls are MFC classes and declared inside the functions of my classes. I'd have to think it should be safe since all of my own classes are deleted before the program's exit. Is there anywhere I should check in particular?

Taking Graham's information,
after define the CRT memory leaks parameter, the message reports one extra memory leak, which seems to be happening within MFC's own code.

Detected memory leaks!
Dumping objects ->
{47} normal block at 0x00C84590, 49 bytes long.
 Data: <h l             > 68 C0 6C 00 0C 00 00 00 20 00 00 00 01 00 00 00 
occmgr.cpp(172) : {46} normal block at 0x00C84530, 32 bytes long.
 Data: <                > EB 03 00 00 00 00 00 00 E9 03 00 00 00 00 00 00 
{45} normal block at 0x00C82E90, 20 bytes long.
 Data: <                > FF FF FF FF CD CD CD CD CD CD CD CD CD CD CD CD 
Object dump complete.
'Prog.exe': Loaded 'C:\WINDOWS\system32\mslbui.dll', No symbols loaded.
'Prog.exe': Loaded 'C:\Program Files\Yahoo!\Messenger\idle.dll', No symbols loaded.
'Prog.exe': Loaded 'C:\WINDOWS\system32\MSIMTF.dll', No symbols loaded.
Detected memory leaks!
Dumping objects ->
{84} normal block at 0x00C86650, 51 bytes long.
 Data: <h l "   "       > 68 C0 6C 00 22 00 00 00 22 00 00 00 01 00 00 00 
{161} normal block at 0x00C86898, 25 bytes long.
 Data: <h l             > 68 C0 6C 00 08 00 00 00 08 00 00 00 01 00 00 00 
{78} normal block at 0x00C86548, 40 bytes long.
 Data: <g               > 67 00 00 00 D3 01 00 00 00 00 00 00 00 00 00 00 
Object dump complete.
The program '[1128] Prog.exe: Native' has exited with code 0 (0x0).

I have tried further to use "Setting a Breakpoint on a Memory Allocation Number" technique described in MSDN documentation. I could not seem to get much out it since the debugging would break at some strange points which weren't the specified block number.

For now, I am wondering, according to that extra memory leak detection prior to the original memory leak, can it be assumed that it might not be my code but has something to do with MFC itself?

Worst of all, if I could not determine the sources of the memory leaks, how much performance hit the app would do to the system. I can see about 120 bytes memory leak from the originally posted memory leak, is that all what should be taking account?

Thanks again

Antti Keskinen11-Feb-04 6:34

Re: Help with memory leak warning message (solved)

11-Feb-04 6:34

Memory leaks can happen in MFC as well if you use it's routines incorrectly. In these cases, you must check through the MFC Reference in order to determine how a certain class is supposed to be used.

As for the memory blocks, put the definition flag and the include files into your stdafx.h file. This causes them to be included everywhere, and respectively, be effective everywhere. Then call the _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); on your application's InitInstance. This gives you the leak information always when your application exits.

Now place arbitary exit points into your application: during it's startup, after the initializations, during a normal run, at the exit phase and so on. This allows you to determine the position in where to look for the memory leaks.

An additional thing about using MFC: Remember that all it's classes are wrappers or containers for Win32 API routines/objects. This having said, always in your code when you create a bitmap, for example, you can, if you want, call the Delete* methods to safely destroy the underlying Windows object. Sometimes, the destructor of MFC's classes does not call this method, thus leaving the underlying object intact, and leading into a memory leak.

It is difficult to advise you any further without actually seeing the code, but that is unfortunately impossible.

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.

J.B.11-Feb-04 17:11

Re: Help with memory leak warning message (solved)

11-Feb-04 17:11

Thanks guys, espcially Antti for the helps,

I had finally found and solved the memory leak problem. I pinpointed it by going back to my each daily souce code backup, find and compare the pair app codes which were before and after the memory leak message was produced. And it turned out to be caused by something which seems rather simple, but I have trouble to understand why.

It's the CStatubar object I've created for my Dialog-based app. It's created within my main class' OnInitDialog()

m_statusbar.Create(this);   /* Create the status bar */
m_statusbar.SetIndicators(indicators, 2);   /* Set number of the pane */
m_statusbar.GetStatusBarCtrl().SetBkColor(RGB(180,180,180));    /* Set background colour */
m_statusbar.SetPaneText(0, "Welcome to m600 Printing Scheduler");   /* Set initial status text */
SetTimer(100, 1000, NULL);  /* Add the clock */

the only difference is that previously it was declared as a global variable and placed on the top of the cpp file, and later I moved it into the class declaration scope (h file) so it becomes a class member. The later has caused the memory leak. I do not quite understand why tho. It looks to me that in the later case, the class memebers (including CStatusBar member) would still have been freed upon the exit of the app, when this main class is desctructed?

This would remind me of the obstacle I had previously also about the CStatusBar. Unlike many other classes (such as CEdit), I realised that I could not simply assign a pointer to this class object I created so that to directly access it in other threads. In debug mode, it'd break and in release mode, it'd compile ok and still do what it is supposed to do (say, to change text, pStatusBar->SetPaneText(0, "Testing");. How is this class different?

Thanks alot guys

Antti Keskinen11-Feb-04 18:41

Re: Help with memory leak warning message (solved)

11-Feb-04 18:41

I believe that it might be a combination of the status bar and a dialog.

As default, the dialog class is not suited for handling a status bar, so you must override the OnOk handler, and explicitly call 'm_statusbar.DestroyWindow' method to destroy the Windows status bar control upon exit. The dialog class is not aware of the status bar control otherwise than that it is a child control. Upon exit, the class issues a WM_DESTROY for all child controls, but for some reason, the status bar does not handle this properly.

So, call the manual destruction method of the class in the OnOk handler. I think this should remove at least one or two of the memory leaks.

The break problem is because of the multi-threading. Accessing a class directly from across the thread is dangerous, because the memory areas might become corrupted. Instead, add handlers for different messages in your status bar class, and register a set of new Windows messages for your convinience. Messages such as WM_MY_SETTEXT and send the new text string in WPARAM and perhaps the ID in LPARAM. Using Windows messages is a safe way to signal changes across threads.

One last option is to try AFX_MANAGE_STATE( AfxGetStaticModuleState() ); call pair. This function sets the thread/module state until end of it's calling scope. Basically, it ensures that all data within this context's (the thread's) memory block is valid. It works smoothly for DLL's, but I am unsure how it affects multi-threaded applications. It might, or might not, help you. Also, make sure you are linking with the multi-threaded version of the MFC library files. Linking with the single-threaded ones in this case might also be the problem.

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.

J.B.12-Feb-04 6:04

12-Feb-04 6:04

Antti Keskinen wrote:
So, call the manual destruction method of the class in the OnOk handler. I think this should remove at least one or two of the memory leaks.

Antti, I further experimented by declaring m_statusbar as a class member and explicitly destroy it upon my overriden OnCancel() call (where all my exit routines go through). Unforunately, to my surprise it did not seem to make any difference. The three memory leaks would still exist, while making m_statusbar as a global variable completely dismisses the memory leaks (at least no longer in the debug window anyway). Can this be explained?

Antti Keskinen wrote:
Accessing a class directly from across the thread is dangerous, because the memory areas might become corrupted. Instead, add handlers for different messages in your status bar class, and register a set of new Windows messages for your convinience.

Yes, SendMessage() is what I've learnt to use later and I found is quite efficient and reliable. However, I am just wondering for those object pointers I previously created for directly class access and have worked successfully within multiple threads, can I be safe to leave them as they are, without having to worry about memory corrupton? Or the corruption is still possible as more objects are being made later.

Thank you again, Antti
Johnny

Peter Weyzen11-Feb-04 7:42

Peter Weyzen

11-Feb-04 7:42

I feel like a walking advertisement, but there's some commercial product outs there that's great for this:

(1) Check out BoundsChecker, it will tell you exactly what code created the memory you wish to free. (http://www.compuware.com/products/devpartner/bounds.htm[^])

(2) SmartHeap -- an alternate memory manager. Detects all kinds of bad memory problems, and also tell you exactly who allocated the memory and it's faster than the VC++ mem manager. (microquill.com)

Neither of these are cheap. But if you figure your time spent chasing memory leaks, they pay for themselves quickly.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>

Graham Bradshaw11-Feb-04 3:49

Graham Bradshaw

11-Feb-04 3:49

Take a look at "Detecting and Isolating Memory Leaks Using Microsoft Visual C++" in MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/memleaks.asp[^]), and in particular, the section "Setting a Breakpoint on a Memory Allocation Number". I've used the techniques in this article to find some obscure leaks (typically the leak is actually in the MFC code, but it's my fault for not using MFC properly).

Reading the USB port

Demian Panello11-Feb-04 2:01

Demian Panello

11-Feb-04 2:01

Hi!

I' have a simple question.

I want to read, (and then write), over an USB port. How can I do that?.
I've thinking to use the CreateFile() API function, but it's only for communication ports.
I need only a few lines of code to get out of this trouble Confused | :confused:

, only to understand.
Thank you.

Regards.

Demian.

Re: Reading the USB port

Antti Keskinen11-Feb-04 2:35

11-Feb-04 2:35

The USB is not just a port.

The USB is a bus. This having said, you can easily imagine USB as a small-scale local area network. Each USB device you have is connected to this bus, and each device is by default equally important.

This means that in order to operate on the USB, you must have an external device that can register itself into the USB Hub controller of your computer. This registration process allows the controller to create a pipe from your computer's address space to the destination device.

I suggest reading BeyondLogic's site's excellent article on the nature of the Universal Serial Bus. You can find this article's first chapter from here[^].

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.

Re: Reading the USB port

Demian Panello11-Feb-04 4:54

Demian Panello

11-Feb-04 4:54

Thank you for your time Antti.

Regards

Demian.

Demian.

edk.h

barzw11-Feb-04 1:08

barzw

11-Feb-04 1:08

Hallo
im new in programming with c++ .net, To solve a problem I found the programm-code "Outlook messages automatically dialog" here in codeproject.com. If I try to compile the code i get errors "edk.h" is missing.

Where I can find edk.h?
Do I need some libs too?

Can somebody help me please? Thank you
Winfried

ps
the problem I have to solve is: automatically to save Files reaching my inbox of Outlook without using an ExchangeServer. If somebody have a good tip? Thanks

Re: edk.h

Michael P Butler11-Feb-04 1:18

Michael P Butler

11-Feb-04 1:18

barzw wrote:
Where I can find edk.h?
Do I need some libs too?

The files used to be included with VC6 and the platform SDK. Since the upgrade to Exchange 2000 and Exchange 2003, they are no longer distributed with VS.NET or the latest platform SDK.

You should be able to download the needed files here

http://www.microsoft.com/downloads/details.aspx?FamilyId=36A309C3-8C55-4476-8785-CAFC59A2D075&displaylang=en[^]

Michael

But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel

machine code

Anonymous11-Feb-04 0:53

Anonymous

11-Feb-04 0:53

hi,
how exactly does an assembler( i know compiler calls an inbuilt assembler) produce the machine code.
what is a binary 1 and binary 0.can i send it to any part by hand?
plume

Prakash Nadar11-Feb-04 1:04

Prakash Nadar

11-Feb-04 1:04

Just like an compiler is programmed to convert C code to Assembly code, an assembler is programmed to convert assembly code to machine language.

for example

to clear the interrupt bit in C you say

disable(); //C - Code
the compiler converts it to
CLI // Assembly code
The Assember converts it to
0xFA // Machine code.

Any digital system like computer works on binary system
i.e
1 logic 1, or on state or conducting state of the transistor
0 logic 0, or off state or non conducting state of the trans

the combination of 0's n 1's in a certain combination does certain task. This is hardwired using transistors, etc aand that we call it as Microprocessor.

You can certainnly do programming 0's n 1's but there are no company who wants to hire such ppl now Poke tongue | ;-P

Well the assembly language may be used in certain case in embedded system but now a days c language has taken over.

Last time I was sober, man I felt bad
Worst hangover that I ever had
It took six hamburgers and scotch all night
Nicotine for breakfast just to put me right.... Dire Straits

Anonymous11-Feb-04 1:13

Anonymous

11-Feb-04 1:13

thanx mr.prakash,

i knew that but what i need to know that is:
what EXACTLY is binary 1? i think the ascii 1 as typed here is not binary 1.
0xff can be written as 11111111 but what are these 1's.??!!

plume
bye.

jmkhael11-Feb-04 1:30

jmkhael

11-Feb-04 1:30

Ascii 1 = hex 31 = binary 110001

Those ones are finaly converted on the machine level to electrical impulsions on the processor which triggers "actions" or flows of 1 and zero forming a language at the machine level.

Reading a book of electronics namely something todo with transistors and logical equations can help

Papa

while (TRUE)
Papa.WillLove ( Bebe ) ;