Any Infragestic control you use leaks memory. In testing, I've found that UltraTextEditor, UltraTabControl, UltraComboEditor, UltraButton, etc... All do not dispose of themselves correct and all are held in memory due to a strong reference from Infragestics.Win.Office2007ColorSchemeChangedNotifier, which is held by a static event handler.
Just recently the major memory leaks with win tree were reduced to a point where it could be used in production code. I did a sweep of a couple sub system to use all Infragestic control to take advantage of themeing and when from 20-30k memory leaked per sub system instantiation to 5 megs+ leaked.
Seeing how bad the leaks are, surely someone has a work around? Is there a hot fix for this yet?
Are the controls actually being disposed? If they are explicitly being disposed (which should happen when they are part of a form's Controls collection and that form is properly disposed), this could be a bug, though I'm not sure.
You may also want to take a look at this thread, which has some discussion on the matter.
-Matt
I had already read that thread. The controls that are leaking are on a pop-up dialog that is in a using statement. I have verified that the form dispose is being called and I explicitly called dispose on all of the ultraButton as a test and use a try finally around the using statement and
GC.WaitForPendingFinalizers();
To insure everything is freeded. However, memory still leaks and I used dotTrace from jetBrains to track down why. Thee is a static class member than holds a reference to an event handler for colorSchemeChanged on every ultra control I use. That event is linked to Office2007ColorSchemeChangedNotifier. The thread you pointed me too has the exact same problem and was indentified in June 2008. Yesterday I installed the latest hot fix and hte problem still persists. I'm shock that after 8 months there is still no fox or work around for this. :(
I am seeing this as well. I have verified that the Infragistic's control is Disposed of and fires its' Disposed event but this static is keeping the control around. I haven't had time to recreate this in a sample app but here is what our memory profile shows after the UltraListView has been Disposed of.
I open a support ticket, the result was that this was expected behavior. :( However, with my pop-up editor usage I'm leaking a couple thousand objects an hour and I run out of reosurce handles and the software crashes. The recommendation from teh support ticket was not to recreate those editors so often. :( I did have a sample program with the support ticket to show case, but with a simple window you are only leaking a couple objects and at most 10k a go, which they deemed harmless.
tribbles,
What is the case number from your support request? I'd like to follow up on this issue to make sure that we've covered all of the avenues that we reasonably can cover.
CAS-17445-P1U2TR
Thanks for confirming the case number.
In reviewing the case, I see that we found a couple of things.
First, there is some increased memory usage whenever a new Appearance object is created, as the Appearance objects hook into our Application Styling Framework. This is expected behavior, because the controls need to be ready to react appropriately if Application Styling is turned on by the application at a later point during execution.
Second, we'd asked for some specific diagnostic information, which we need to continue our research. There may be other things causing an apparent memory leak besides the ones related to application styling. We never received the requested information, and so we cannot confirm whether there is or is not a memory leak.
If you can provide the requested diagnostic information, you can reopen the support case within 30 days of its closure, and we will continue research. After 30 days of the case's closure, you can instead submit a new support request and refer to the original one.
We checked the support case you mentioned and there was no sample provided - only screenshots - so I'm not sure what you mean in your previous posts about the test case leaking window handles. If you can provide that sample (here on the forums or to the support group) then we can look into why you are finding that the controls are not cleaning up properly.
I was wrong. We had a case were we weren't disposing of an Infragistics control so the problem was ours not Infragistics. Since Matt double checked your source code and said the Dispose should be cleaning as expected, I went back into our code and looked much deeper than I initially did and found a case were one of our controls was creating an Infragistics control but not adding it to its' own Controls collection so when it was disposed of the child control (the Infragistics control) was not and that is what the memory profile screen shot was showing. When I saw that, I googled for this issue and found these forum entries and assumed my issue was related. While preventing a control's finalizer from being called and thus preventing the Dispose from being called is a problem, it is not what was leading to our issue. We are using CAB and so when a WorkItem is terminated, its' SmartParts are disposed of so I am not as concerned about having to manually call the Dispose on a control to get this clean up to happen since CAB will do this for us. Long story short, I am once again a happy customer. Although once I cleaned up this issue, I found what looks like a similar issue where we are leaving a UltraWinChart.IGWinTooltip.LocationChangedHookedControls hooked up. I assume we are not disposing of a Infragistics chart control here.
Both ANTS and dotTrace both point out that Infragestics objects are prevents the dialog windows from being fully GCed. You have a sample the show cases the problem, it replicates the problem on my system. Whether you want to believe me or these otehr fine gentleman or not is your perogative. Regardless, until this critical design flaw is fixed, I can not use your product in a production setting nor recommend is use on government contracts. This is really heat breaking as you have the best lookign stuff on the market, it is just a shame it is not functional.
I have confirmed the Infragistics controls are being disposed of but yet are not being GCed due to the hookup shown in the dotTrace screen shot. We are using the AppStyling runtime and we load 2 different style files (isl files). One style file has the styles that are shared between all of our applications and one style file has the styles specific to a particular application. I haven't had time to try a couple of different things or build a sample app. I'll try to get to it this weekend. Unfortunately, I have a client starting a new application development effort and I can't recommend the control suite until this is resolved.
I'm not sure if this is the same case but a recent memory leak report that I reviewed had a screenshot of a dotTrace output. The majority of the things in the screenshot were AppStyling related objects that are statically stored. These are not memory leaks. As you created and showed multiple instances of a form, those would not increase - it was a one time hit as the application styling metadata for the assemblies were loaded. The other things I saw in that were UltraWinTree classes but the main window that was still displayed contained an UltraTree so that is why those objects were there. Again, perhaps this is a different case but I just double checked the code and the event you mentioned in the initial post is hooked in the ctor of the UltraControlBase (the base class for controls such as UltraButton, UltraListView, etc.) and unhooked in the Dispose method of the UltraControlBase so as long as the Dispose method is called then that method will be unhooked. Can you post the sample project you provided with which you are seeing the issue?