Serious Infragestics memory leak with their controls

This post has 18 Replies | 3 Followers

tribbles
Points 907
Replied On: Thu, Feb 19 2009 7:29 PM

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?

  • Post Points: 20
Matt Snyder
Points 37,774
Replied On: Fri, Feb 20 2009 11:58 AM

 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

  • Post Points: 20
tribbles
Points 907
Replied On: Fri, Feb 20 2009 5:49 PM

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.Collect();

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. :(

  • Post Points: 20
Matt Snyder
Points 37,774
Replied On: Mon, Feb 23 2009 10:17 AM

I just took a quick look and I do see the call in the Dispose method to unhook the event handler for the ColorSchemeChanged event of the Office2007ColorSchemeChangedNotifier, so I'm not really sure why this would still be rooting a control.  If you're absolutely positive that the Dispose method is being called for all Infragistics controls, then you should probably submit a small sample to Developer Support so that it can be looked into.

-Matt

  • Post Points: 20
Pat H
Points 225
Replied On: Mon, Mar 16 2009 11:20 PM

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.

  • Post Points: 35
tribbles
Points 907
Replied On: Tue, Mar 17 2009 12:31 PM

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.  

  • Post Points: 35
Replied On: Tue, Mar 17 2009 12:57 PM

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.

Vince McDonald
Senior Developer Support Engineer, MCP

Need help? Find the various ways you can ask for help from Infragistics.

  • Post Points: 20
tribbles
Points 907
Replied On: Tue, Mar 17 2009 7:54 PM

CAS-17445-P1U2TR

  • Post Points: 20
Replied On: Wed, Mar 18 2009 2:28 PM

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.

Vince McDonald
Senior Developer Support Engineer, MCP

Need help? Find the various ways you can ask for help from Infragistics.

  • Post Points: 20
yossin
Points 215
Replied On: Thu, Mar 19 2009 1:15 PM

Hi, we encountered this issue a while back in vol 7.3 we have a workaround for this issue.

i don't know if it will work with current versions, but you can try.

the solution and explanation of the problem (basically infragistics is rooting all controls to static event handlers) can be found here

(http://subjectively.blogspot.com/2009/03/importance-of-recycling-memory.html)

  • Post Points: 5
tribbles
Points 907
Replied On: Thu, Mar 19 2009 1:38 PM

The test case associated with the case leaks window handles  and memory each time you open and close the dialog.  Same thing happens with my product code, the onyl difference is I leak over 50 handles and a couple megs each time, while with the test case I believe it is only 5 or 6 handles and a few K.  Over an 8 hour work day, average usage will have these dialogs opened 240-300 times.   With a limite of 10k handles...  Well, the software will crash between 100-200 dialog openings.

Regardless of whether it is by design or not.  To have *ANY* thing leak after closign the dialog and garbage collection is unacceptable.

  • Post Points: 50
Replied On: Thu, Mar 19 2009 4:27 PM

I notice you mention "dialog".  Are you showing a form using its .ShowDialog() method?  If so, then the .NET Framework won't explicitly dispose the form when you close it.  As a result, any controls on the form, and their corresponding resources, may not be garbage collected.

If this is the case, then you should explicitly call Dispose() on your dialog when you're done with it.  This will implicitly dispose all controls (including ours) that appear in the dialog's Controls collection (and any controls in their Controls collection).

If that's not the case, then we'll need to investigate this in more detail.

Vince McDonald
Senior Developer Support Engineer, MCP

Need help? Find the various ways you can ask for help from Infragistics.

  • Post Points: 20
Replied On: Thu, Mar 19 2009 5:52 PM

pathennessy, I've verified that we are unhooking that event in the Dispose override of the control so either the control is not being disposed, its being removed from its parent before you disposed the parent (this would be ok if you explicitly disposed the listview) or another instance of the control is being created - sometimes this happens inadvertantly when allocating a member variable. e.g. Dim ul as New UltraListView ul = sender as UltraListView

  • Post Points: 5
tribbles
Points 907
Replied On: Thu, Mar 19 2009 7:06 PM

I already went over all of that in the ticket.   The example provided show cases items being leaked.   Support response was that this was by design and that my hamdle/memory leak must be something else.  I provided screen shots of my application leakign the same objects, just in much higher numbers, I believe there are 56 instances on 1 object in the screen shots provided.  Same objects as in the example., just in greater numbers.  My manager is refusign to assign any more time to this project and I've had to revert back to non Infragestic controls, like I have had todo multiple times since 2005 on any consumable control (tool window, dialog, etc...).

The uage for the dialogs follow the using pattern, i.e.

using

 

 

(SelectTemplateDialogForm form = new SelectTemplateDialogForm

(type)) {

 

 

 

  • Post Points: 20
Replied On: Thu, Mar 19 2009 10:06 PM

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?

  • Post Points: 35
Page 1 of 2 (19 items) 1 2 Next > | RSS