Link to home
Start Free TrialLog in
Avatar of Evan Li
Evan LiFlag for United States of America

asked on

Using Diagnostic tools in VS2015: Unresoved allocations

I found memory leak by using Visual studio 2015, for my c++ program. What I can see the leak is "Unresloved alllocations", and double clicked the leaked row, I got a list of addresses, I have attached the first page as "unresolvedAllocations.png" second page as "unresolvedallcationlist.png", I do not know which one is the real leak it is indicated here, does anyone knows how this works? Thanks for any help.
UnreslovedAllocatoions.png
UnreslovedAllocatoionsList.png
Avatar of sarabande
sarabande
Flag of Luxembourg image

103 bytes is near to nothing. looks as if some string comparision still has a few small buffers not yet freed what probably is not a leak but quite normal if you do such an analysis while debugging.

can you post the original leak messgae and the code that might have caused the leak?

Sara
Avatar of Evan Li

ASKER

Sara, Thank you for answering. My code is very large, I am now Isolating the code to find where it could cause the problem. Looks that when I open the modal dialogbox, it has the leak, I am trying to confirm this.

Thanks.
Avatar of Evan Li

ASKER

In fact, when I used task manager to observe , it increases 200k each time. I have linked to Visaul Leak Detector, when I close the program, VLD reported no memory leak.
when I used task manager to observe , it increases 200k each time
task manager is not a reliable tool for measuring or detecting leaks, especially if you run it in the debugger. the problem is, that task manager will not count smaller freed blocks of memory which happen to exist because of defragmentation of the heap space. assume your program has allocated a byte array of 900 bytes and needs to increase it to - say 1100 Bytes. then, the heap manager would reserve a new block of - probably - 2048 bytes for the new array. after the data were copied from old to new, the heap has a free "leak" of 1024 bytes where the old buffer has been located and a reserved area after the new buffer. both spaces will not decrease the memory shown for your process because they are reserved and badly can be fully used for new allocations.

note, in c++ you should do all (at least most) allocations within class objects and free the memory in the destructor. then, if you allocate the class objects at the stack rather than on the heap and especially avoid containers with pointers, you have a good chance, to minimize the risk of leaks.

Sara
Avatar of Evan Li

ASKER

Thank Sara for your answer. Usually customer or my manager tell me that I have a memory leak by using the ? Task manager. Is there a tool can accurately tell me if I have memory or not? Yes, I believe what you have said.
Is there a tool can accurately tell me if I have memory or not?
not from outside. you could make a memory dump (to file) at some point in code. then compare two dumps to see if there are salience (there are functions to compare dumps and also tools as far as i know).  the best way in my opinion is to have  a good design. if you were using containers that will grow, reserve enough space at the beginning. that will fasten your code and keep memory stabile.

note, a little growing of memory consum is normal. you can't really avoid it (beside you periodically would start a new process and pass the tasks from old process to new one).

if the client computers have physical memory of 8 GB or more, it never should make an issue,

Sara
Avatar of Evan Li

ASKER

In fact, my program is running in the process of tray icon, and it will be accumulate until user logout. So I need to be careful. So leak is not allowed even a little.

I have Visual Leak Detector, Microsoft Visual Studio Diagnostic Tools, and CRT memory test APIs, each of them telling me different result, VLD says that I do not have leak, but Visual Studio Diagnostic tools says I have a leak, CRT API says I have leaks in different places that identified by Diagnostic tools.
Avatar of Evan Li

ASKER

I have posted another question that is might be Microsoft problem:
https://www.experts-exchange.com/questions/28976599/Dialogbox-API-leak.html
Microsoft Diagnostic tools detected Microsoft DialogBox API leak. Sounds strange to me.
Thank you.
detected Microsoft DialogBox API leak. Sounds strange to me.

it is not strange. for DialogBox you provide buffers to take data. if the buffers are not freed after return of dialog box, you will encounter a leak.

Sara
Avatar of Evan Li

ASKER

Sara, I do not understand at all.

If you are calling dialogbox, you do not need allocate any memory, You do not even need to load resource. you just tell dialogbox API what it is, it will open the dialog for you. When the dialog close, we call enddialog in call back function. There is no way I can deallocate any buffer at all.
what kind of dialogbox you are using? is it mfc CDialog? or do you load dialogbox from resources? how do you initialize controls? by dialogproc? how do you get input values from dialogbox? is there any structure or class that handles all this.

if CDialog the EndDialog may not be called from callback but by a CDialog handler (for example if the cancel button was clicked). calling EndDialog in an asynchronously running callback is not thread-safe and may hinder the Dialog to free its resources ==> now you have a leak.

Sara
Avatar of Evan Li

ASKER

Please refer to the question here:
https://www.experts-exchange.com/questions/28976599/Dialogbox-API-leak.html?anchor=a41845621&anchorAnswerId=41845621#a41845621

I have source code there.

I have used pure Win32 API, Just use wizard to generate a simple Win32 APP, for about dialog, if you set parent window handle to be NULL, when you use the diagnostic tools before dialogbox and after dialogbox, you'll see leak, but there is no resource load or memory allocation here.
but there is no resource load or memory allocation here

and what is about:

wcex.hIconSm        = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

Open in new window


where did you free this resource?

can you show a picture of the dialog or post the rc file?

note, a visual c++ program uses a framework via stdafx.h. even if you use c code for dialog processing you still catch some automatic instantiations from framework. in the debugger things go worse since the debugger needs to make extra allocations for each variable you used. so if you detect leaks while running the program in debug mode but can't detect leaks in release mode, all your efforts are wasted.

Sara
Avatar of Evan Li

ASKER

I have attached the rc file and cpp files at this location, let's talk in that question thread.

https://www.experts-exchange.com/questions/28976599/Dialogbox-API-leak.html?anchor=a41845621&anchorAnswerId=41845621#a41845621
IMO the LoadIcon can't be the problem since it is only called once from WinMain, so it can't be the reason for repeatedly memory leaks with each dialog open/close.

As written in the other task I think you can't do anything against this kind of memory leak (since it seems to come from deep inside some Win32 API call) except not using NULL as parent windows paramter.

The question still is: why do you want to pass NULL here? I think it is not a good idea to do so because DialogBoxParam in this case doesn't create a really modal dialog, so the main window isn't disabled and can be activated, this way it's even possible to open more than one About dialogs. In other words: dialogs created this way act more like a modeless dialog allthough the function DialogBoxParam is intended to create modal dialogs.

If your intention to pass NULL is to make the dialog modeless you shouldn't use DialogBoxParam, instead you should use CreateDialogParam to create the dialog and ShowWindow to make it visible.

ZOPPO
BTW: In fact, my program is running in the process of tray icon, and it will be accumulate until user logout. So I need to be careful. So leak is not allowed even a little.

Of course in general I agree, memory leaks shouldn't occur at all if possible.

But in seldom cases like this where the leak is quite small and occurs in API calls only after a user action it probably can be ignored. Imagine each time the dialog is opened and closed again a memory leak of 1 kB is created - to get this wasting i.e. 10 MB a user would have to open/close the dialog 10000 times using 30000 mouse clicks. It is very unlikely someone can/will open/close dialogs so often (it would mean opening/closing a dialog every 2,8 seconds during a 8-hours workday). Even if running multiple days/weeks this shouldn't be a problem, 10 MB of wasted memory is hardly ever a problem, even some hundred MB may not cause any harms, especially with 64-bit builds and heaps of GBs computers are equipped with nowadays.
Avatar of Evan Li

ASKER

Thanks Zoppo,

I am asking the general question, I am just listed one of the simple easy to repro problem here, In fact I can find many places in my program, I got this "unresolved allocation" leak, I could not find where my code is wrong, by listing the possible leak call stack, I just could not find how I can fix it. I do not even have a way to work around like dialog, I can add an window handle, in many situation, I do not have this option. What you do with this kind of situation?
ASKER CERTIFIED SOLUTION
Avatar of Zoppo
Zoppo
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Evan Li

ASKER

Thank you Sara and Zoppo, I am closing this question at this time. I'll post more questions related to meory leak debugging later. Thanks.