Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Mmemory leaks when exiting application Collapse All
Subject Author Date
Offer Har Jan 19, 2009 - 8:32 AM

Dear Support,


When we exit Prof-UIS (regardless of the version) we get a lot of memory leaks, that runs for a long time, and the only way to gain back control over the environmnet is to kill the DEVENV task and re-run it. Please let us know whaat is the problem, and if we need to give some special handling to Prof-UIS when the application terminates.


This is the beginning of the memory dump:



   * * * TERMINATING DYNAMIC LIBRARY: ProfUIS version 2.84 * * * 
Detected memory leaks!
Dumping objects ->
..\Src\ExtCmdIcon.cpp(6836) : {45488} normal block at 0x03A60E58, 28672 bytes long.
 Data: <			    > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD 
..\Src\ExtCmdIcon.cpp(6836) : {45487} normal block at 0x03A67E98, 28672 bytes long.
 Data: <			    > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD 
C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include\afxtempl.h(406) : {44120} normal block at 0x039C9AC0, 16 bytes long.
 Data: <			    > 00 00 00 00 13 00 00 00 00 00 00 00 13 00 00 00 
f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\array_p.cpp(110) : {41423} normal block at 0x039C9E58, 124 bytes long.
 Data: <    H		   > DC E0 9F 03 48 E1 9F 03 B4 E1 9F 03 20 E2 9F 03 
{39367} normal block at 0x03A0CE38, 24 bytes long.
 Data: <`	   `	   > 60 DD 9D 03 C8 B8 A1 03 60 DD 9D 03 0B 00 00 00 
f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {39366} normal block at 0x03A1C110, 25 bytes long.
 Data: <, ?x		    > 2C 08 3F 78 08 00 00 00 08 00 00 00 01 00 00 00 
{39360} normal block at 0x03A1B8C8, 24 bytes long.
 Data: <p   0   8	   > 70 A0 A1 03 30 C8 9F 03 38 CE A0 03 0A 00 00 00 
f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {39359} normal block at 0x03A1B920, 25 bytes long.
 Data: <, ?x		    > 2C 08 3F 78 08 00 00 00 08 00 00 00 01 00 00 00 
f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\array_p.cpp(110) : {39357} normal block at 0x03A1BC38, 36 bytes long.
 Data: <    @    (  45  > DC F0 A0 03 40 17 A1 03 20 28 A1 03 34 35 A1 03 
f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\array_p.cpp(110) : {39356} normal block at 0x03A1BBD8, 36 bytes long.
 Data: <    @    (  45  > DC F0 A0 03 40 17 A1 03 20 28 A1 03 34 35 A1 03 
{39351} normal block at 0x03A1B7A8, 24 bytes long.
 Data: <`	   `   F   > 60 DD 9D 03 E8 B6 A1 03 60 DD 9D 03 46 CB 0D 00 
f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {39350} normal block at 0x03A1B868, 34 bytes long.
 Data: <, ?x		    > 2C 08 3F 78 11 00 00 00 11 00 00 00 01 00 00 00 
f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\array_p.cpp(110) : {39348} normal block at 0x03A1B808, 36 bytes long.
 Data: < A  pA   A  HB  > 04 41 A1 03 70 41 A1 03 DC 41 A1 03 48 42 A1 03 
{39343} normal block at 0x03A1B6E8, 24 bytes long.
 Data: <`   (	   E   > 60 DD 9D 03 28 B6 A1 03 A8 B7 A1 03 45 CB 0D 00 
f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {39342} normal block at 0x03A1B748, 35 bytes long.
 Data: <, ?x		    > 2C 08 3F 78 12 00 00 00 12 00 00 00 01 00 00 00 
{39336} normal block at 0x03A1B628, 24 bytes long.
 Data: <		    D   > 88 C5 A1 03 C8 C4 A1 03 E8 B6 A1 03 44 CB 0D 00

If continues to dump something that looks like all of MFC...


Thanks,


Ron.

Technical Support Jan 20, 2009 - 5:29 AM

The 45488 number in the following text is the invocation number of the malloc() function:

..\Src\ExtCmdIcon.cpp(6836) : {45488} normal block at 0x03A60E58, 28672 bytes long.
 Data: <                                        > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD

So, if you invoke the _CrtSetBreakAlloc(45488); code during your application initialization (you can invoke it in the constructor of the CWinApp-derived class) and start debugging it, then the debugger will break execution when the malloc() function is invoked 45488 times. You will be able to take a look at the call stack and find what and where is allocated. We recommend you to find the smallest allocation number in the Output window. This allocation is the earliest memory leak in your application and other/later leaks are often dependent from this leak. If the earliest leak is pointer to the main frame or dialog window, then the most of allocated objects are not destroyed in your application due to some critical or unhandled situation. The easiest way to created big count of leaks is to invoke the ExitThread() or ExitProcess() APIs.

You can change the exception handling options while debugging your application and make debugger breaking its execution for all the exceptions independently from whether they are handled or not. For instance, if exception is occurred during the application de-initialization, then it’s typically handled but most of dynamically allocated objects does not become destroyed. Please note, the exception occurred in the other exception handing code is assumed as unexpected exception in C++ and causes process termination.

The final and absolutely universal way of finding problems is commenting parts of code and finding configuration which does not generate the problem.