ThinkGeo.com    |     Documentation    |     Premium Support

Is there a Memory Leak when disposing of WinformsMap?

#1

My application is a tabbed application with an instance of the desktop WinformsMap control on each tab. When a tab is disposed, I would expect the memory that was allocated the Map to be returned, but it is not. It just piles up in the Gen 2 heap. As tabs are opened and closed the accumulated allocations eventually cause problems.


To illustrate the issue I made a simple VS2010 project. I has 'Add Tab' and 'Remove Tab' menu selections. With those you can create a collection of tabs, each with a WinformsMap object preloaded with a 1.5meg PNG image, and then remove them.


Run Resource Monitor (or your favorite profiler) and watch the memory allocs as you add tabs.  Then watch the allocs remain as you remove tabs. I have let this run for 8 hours and the garbage collector never de-allocs the memory (like I said, stuck in Gen 2 heap).


It looks like the WinformsMap is not releasing its unmanged resources correctly. Am I correct?


Dave


(I tried to attach the project, but it is limited to only 500kb... I will send it in email if you will tell me where to send it)



#2

David,


Thanks for your post and questions.
 
I think you can send the sample to our support (support@thinkgeo.com) and ask to forward to James and Yale for this post. I am curious how your preloaded the 1.5meg png image, is it using the GdiPlusRasterLayer? If so, could you try to call the close API for the GdiPlusRasterLayer when you are going to remove the tab?
 
Any more questions please feel free to let me know.
 
Thanks.
 
Yale

#3

Davied, 
  
 This post is related to another post what you talked about, the link is that: 
  
 gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/3/aft/4585/afv/topic/Default.aspx#23688 
  
 According to your descriptions on the post above I think you talked about the Desktop edition 2.0, not Desktop 4.5, please check your first post above, I think the code what you provided is related to the desktop edition 2.0. 
  
 Please tell us the exact version for your product version so that we can resolve your problem correctly, 
  
 Thanks, 
  
 Scott,

#4

 Sorry for the delay, somehow I did not notice your reply...


I am using Map Suite Desktop Full Edition 4.5


Dave



#5

 


David,


I have tested the sample application what you sent to us, but I didn’t find the memory leak problem when disposing of windows map,  before I added tabs, here is the status of the resource manger below:


before.jpg640×511 71.9 KB


 


Then I added 10 tabs, here is the status of the resource manager below


middle.jpg640×510 71.2 KB


You can see the memory spent 23M, last, I removed all of the 10 tabs, here is the status below:


 


 


last.jpg640×510 71.1 KB


 


 


According to the screen shots above, you can realize when disposing the winforms map the memory was released, the version number of desktop edition what I tested is 4.5.0.0.
 
If you are sure there is a memory leak problem when disposing the winforms map please capture the detailed screen shots for us,

Thanks,


Scott,



#6


 Scott,  thank you for the detailed analysis.  Can you take a look again outside  of the IDE? That is, build the app and run it 'native'.  When I do that  I see the following:


Before adding any tabs:




 


One tab added:



 


One tab removed (back to no tabs)



Dave


 



#7

Dave, 
  
 We have added the code for disposing the resources of winform map, please get the latest Daily Build of Desktop edition and try again, if you still find out any memory leak problem please let us know, 
  
 Thanks, 
  
 Scott, 


#8

I have just obtained and installed build .148 and the leak is still occurring.


If you refer to my last post in this thread you will see that I ran a simple 'add one, remove one' test with the MapMemTest application. I just ran the same test with the .148 DLLs and got the following results:


Before: 3,752

During: 12,944

After: 10,880


As you can see, removing the tab releases only a portion of the memory. My guess is that the released portion is the portion used by the Windows.Forms.TabPage object and that the Map object is still allocated.



Dave




#9

Dave, 
  
 Here is my test result below: 
  
 Before: 14,942 
 During: 22,044 
 After: 18,844 
  
 So there are a little memory leaks when remove a tab, but I checked the core code, we have release almost all of the objects when disposing the map, currently, I’m not sure which object is till allocated, I have to look for a memory profiler to monitor it. Also do you know any good memory profiler for vs2010?  
  
 Thanks, 
  
 Scott, 
  


#10

FYI - We have noticed a similar issue.  We have an MDI app and users can open and close the child form, which contains a map, over time the memory will continue to grow.  We are specifically disposing the map and setting it to null, but the memory never gets reclaimed. 
  
 Thanks 
  


#11

Ed, 
  
 We are monitoring the memory useage by the memory profiler, but according to the monitor we didn’t find out any memory leak problem in the ThinkGeo namespace that includes its sub namespaces. But we found out there are several byte and string array were not been release. We are investigating it now to see if there are any array in our product dose not release. 
  
 Thanks, 
  
 Scott,

#12

Scott, 
  
 After furthur investigation, I agree with your statements.  We  were not setting the MDIParent property to null OnCLose of the child  so it was holding the refernences.  I have noticed what seemed like extra system objects, but I think it is minor. 
  
 Ya’ll are going a great job!! 
  
 Thanks, 
  
 Ed

#13

 I am not sure I would have used the term 'little' memory leak... in your own test, only 45% of the allocated memory is released, meaning 55% of memory allocated is leaked...


I am sorry that I can not recommend a good memory profiler for VS2010, I don't need one often enough to own one...


Dave



#14

FWIW, I have a similar scenario, and I have not encountered any systematic and noticeable memory leaks using build 4.5.121.0. I am using Red Gate ANTS Memory Profiler and, other that what look like the static instance of a few MapSuite and related classes, nothing relevant seems to be hanging around after a few GC cycles. That said, a larger number of instances than I would usually expect seem to be making it to gen 2. However, it isn't really a high enough priority for me to dig into at the moment given that it isn't causing any noticeable performance degradation.


Nicole



#15

Guys, 
  
 I used the ANTS memory profiler to test the memory leak problem, the same result as the previous memory profiler tool, there are several string and byte array are not released, all of the bitmap objects in the MapSuite component had been released correctly. I will continue to look for the place where is the memory leak. 
  
 Thanks, 
  
 Scott,

#16

Scott, any news from your effort to ' look for the place where is the memory leak'?


Dave



#17

David, 
  
 We have added this issue to our issue list and we are preparing the May public release. When we are available we will keep research on this if there are any updates we will let you know, 
  
 Thanks, 
  
 Scott,

#18

David, 
  
   The May release stuff should take about two weeks or so and right after that we will re-launch the investigation.  I am not that familiar with this issue but it seems that Scott was saying that there are just a few string etc.  Are you seeing allot more memory not being released than that David? 
  
 David: Can you quantify, with any recent changes Scott has made, how much memory gets leaked using the sample app you sent us? 
  
 Scott:  Can you quantify how many resources are not being releases from what you are seeing? 
  
 I want to make sure that we are all talking about the same thing and that we quantify what may be leaked and where. 
  
 David

#19

Yes, I can quantify the leakage with the sample app; please see my post in this thread from 03-28-2011 03:17 PM


Dave






#20

 Dave,


I did a further tests used a memory profiler tool to monitor the memory useage, according to the monitor result it seems the memory leak is not from our core code, we release all of the necessary objects definitely. Here is the monitor results below:


1, Before ran the application:



 


2, I added 10 tabs:


ran.JPG640×520 115 KB


 


You can see there are several objects appeared that belong to ThinkGeo namespace.


3, I removed all of the 10 tabs:


afterran.JPG640×504 101 KB


 


You can see all necessary objects that belong to the ThinkGeo namespace were released, you can compare the third screen shot to the first screen shot, you can see the memory leak is main from the System namespace for the string and some arraies. 


I sorted the memory byte for each object according to the descending order so that we just need to focus on the top 5 objects in the list. 


Also we will continue to track where is the memory leak if there are any updates we will let you know,


Thanks,


Scott,