Hello everyone, I have a webgrid that sits in a warp to handle the postbacks generated by an ultraClacManager attached to the grid. This combination of controls causes a memory leak in IE, IE consumes about 1000 - 2000k per trapped postback and grows without limit. This has been identified originally as a bug by Infragistics as BR26172. My Question to anybody that has run into this problem is; have you found a work around short of removing the warp and asynchronous postbacks? I have tried wrapping the grid in an ASP.NET UpdatePanel however the Ajax extensions seem to be incompatible with the infragistics controls. This bug has delayed the move to production for 2 months now and we all know this is not good. Any help or incite would be greatly appreciated. Thanks in advance,Patrick
Memory leaks are usually caused by object closures or event handlers that were never detached. The process of detaching the grid happens through a javascript function - igtbl_unloadGrid(gridName,isSelf) Many times when AJAX is involved, detaching previous event handlers is a delicate matter. First check and make sure you're not manually adding any event handlers (to html elements) or creating any closures. If you have client-side event handlers defined for the grid, try removing them and testing the affect on memory to see if they're contributing.
NetAdvantage for ASP.NET should work with ASP.NET AJAX Extensions, so any issues you find with that respect should also be submitted to our support department as a bug.
Hth,
-Tony
Hi Patrick,
The first thing that we need to understand is if this is a client-side or server-side memory leak that you're referring to. Are you looking at the memory consumption for the IExplorer process on the client machine, or the ASPNet_WP process on the server? My initial impression was that you were running into a client-side memory leak which slows down the browser. However, your memory profiler is giving you information on server-side objects and memory.
On the Web server, instances of GridItemStyle are not being disposed properly. In my case, undisposed instances of GridItemStyle are growing by about 1000 per postback. On the client machine the instance of IE is growing in size by 1 - 2 megs each postback. I have not yet tried to install the latest hotfix, I had not heard that anything in the hotfix is related to this issue.
The first thing to remember is that what happens on the server, stays on the server (and has nothing to do with the client memory). Undisposed instances of griditemstyles do not necessarily corespond to a memory leak, unless they are rooted objects. If I recall, there was actually a bug in the .NET Framework's implementation of the Style class, in which it didn't properly dispose itslef. This wasn't necessarily causing a memory leak, but it did cause the objects to live on until 2nd gen of the garbage collector. Unless you're dealing with memory crashes on the asp.net worker process on your webserver, you probably want to focus your attention on the client.
The client is where you'll see a dispose pattern implemented for the Infragistics controls (via javascript). Detecting memory leaks in a browser can be tricky though. Memory consumption will steadily increase in IE until it reaches a magic number, and then the garbage collector will kick in. Generally, running thorugh the same process for a few minutes will stabalize at a max memory consumption. If it continues to grow after a few minutes, at the same rate, then you're likely looking at a memory leak on the client.
Tracking down leaks is even more tricky, but there are a couple of utilities out there including "drip".
It sounds like this is easy to reproduce, and in a simple context so I would certainly recommend you report this to our dev support team (http://ko.infragistics.com/gethelp) Just be sure that when you report it you keep the client-side memory and server-side memory issues separate. If you're seeing increased mem consumption in the client-browser, that really can't have anything to do with undisposed griditemstyles on the server - so I'd recommend not adding this additional variable into the equation.
Hi Kiran,
Did anything come of your support case? We are seeing the exact issues you are describing with 2010.3 release (utilizing mainly the non-akido "Ultra" controls... except modal window).
Kiran,
Have you tested the behavior with the latest hotfix? There were some fixes made to client-side memory management that may help. If that doesn't work, I'd like you to submit this as a bug so our engineering team can investigate a little more. Would you mind submitting this through the more formal online-support channel? It makes it much easier to track the progress. You can submit it through http://ko.infragistics.com/gethelp
Regards,
Hi Tony,
We are (using Infragistics2 v.7.3) facing exactly same problem. We are using fixed number of iframes in div tabs and as we click through those tabs iframes will be targetted to different pages with infragistics webgrid, webcalendar etc controls. Each time we switch through tabs IE process memory increases depending on number of webgrids in that page. This memory never goes down and reaches up till 800MB+ and system stops responding. Client side page unload event is definately firing up in our case because we have a clientside event firing that shows waiting gif image on page unload. So I dont understand why webgrid is not disposing when we switch through tabs. We are using setTargetUrl method to assign different addresses to iframes which is equal to setting IFRAME'S source to about:blank (as per your suggetion).
Is there any client side dispose event for webgrids and other infragistics controls to free up when page is unloaded, or is there any way to see whether the wegrids are unloading while page is unloaded.
- Kiran
IFrames (especially dynamically created IFrames) can be very tricky when it comes to memory management. Any objects created inside of the IFrame will use up memory. When you remove the IFrame element from your page, it's not unloading the page that was loaded inside of the iframe - it's simply detaching the element from the DOM. The WebGrid listens to the page_unload event and goes through it's own dispose method which is used to 'free' up memory that IE would otherwise neglect to collect. It sounds like you're causing the objects to get lost by detaching the IFrame element from the document, without the grid first being disposed.
My suggestion would be to manually unload your page. Try setting the IFrame's source to about:blank rather than BLOCKED SCRIPTreturn false.
The modal popup may also play a role in this as well, though I don't know the code well enough to be sure.
I'm going to send a note to our docs team (they own the online help) and notify them of the possible memory leak. Thanks for pointing that out. I'll let you know if/when they figure out what caused it.
Hi
We found memory leaks in UltrawebGrid control, Japanese Version - NetAdvantage for .Net (Jp) 2007 Volume 1 CLR 2.0 [simple vanilla webgrid without any client side events].
Herewith I attached a sample webApp [http://ko.infragistics.com/TestProjectUploads/ModalTest331200843010468.zip] and my test procedure to repro the bug . I would appreciate your immediate help to get away this memory leak because it is stopping us to release our application in to the production environment.
Steps to Reproduce:
S/W Requirements:1. Visual Studio Web Developer Express / Visual Studio 20052. ASP.NET AJAX Extensions 1.03. AJAX Control Toolkit (Version 1.0.20229)4. NetAdvantage for .Net (Jp) 2007 Volume 1 CLR 2.05. IE 6.0.2900.21806. JavaScript Memory Leak detector http://blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx Setup:1. Create an asp.Net C# WeSite as "Modaltest" in Visual Studio.Net2.02. Unzip the web Application in to the "Modaltest" path 3. Start the web ApplicationTest Procedure:1. The Sample application has got a default (default.aspx) page with one button and a dropdown list to choose Ultrawebgrid control [or] asp.Net gridview control2. Upon Click on the button, I am loading an Iframe dynamically with data grid (UltrawebGrid/gridview based on the selection) in it in a modalpopup (ASP.NET Ajax Control)3. I used JavaScript Memory Leak detector http://blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx and simultaneously monitored memory used by the IE in the performance Monitor.4. I found the amount of memory used by the IE keeps on increasing between 10-13 MB for each button clicks if UltrawebGrid is selected from the list (I.e. loading UltrawebGrid inside the dynamic Iframe) Note: Iframe dynamically created during button click and destroyed during cancel/Ok buttons of the modal dialogBut if Microsoft gridview is selected (I.e. loading ASP.NET gridview control inside the dynamic Iframe), the amount of memory usage is consistent between each button clicks!I have tested your Netadvantage online help webpage for such memory leak http://help.infragistics.com/NetAdvantage/NET/2007.1/CLR1.x/Because some of our web pages have got similar functionality like Netadvantage online help i.e. search results in the Frame. Surprisingly I found that the amount of memory used by the IE keeps on increasing for each Search (Go Button) click!
I highly appreciate your help.
Thanks and regards,Senthilnathan Karuppaiah