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
Thanks Patrick.
Did the private release you tested fix the memory leak?
Erik
The test was inconclusive. I reported the behavior of the private release and I have not heard anything back. It's possible that it did fix the leak but I was unable to get the project in question to render correctly using the new code. All but two of the objects on the page stopped rendering and there were no errors thrown.
I have noticed that minimizing the page for a couple seconds seems to trigger IE's GC.
Sorry I can't be more help.
Patrick
I'll see if I can find out what's going on here. It's possible that the private build had a regression issue that cropped up. Don't be fooled by memory drops when minimizing the browser - it's only reducing the workingset of memory used for the browser, it's not actually clearing up any objects.
I just looked up the bug info and see that this is marked as fixed and for release in the next public hotfix.
Patrick, I'm not sure why you never received any updates on the status of the bug, though I fear it is my fault. Because I went around the standard channels to get you the private fix, your name was probably never associated with the bug. My appologies.
Here's the relevant info:
Fixed in Versions: 6.3.20063.1090 CLR 1.x, 6.3.20063.1090 CLR 2.0, 7.1.20071.1066 CLR 1.x, 7.1.20071.1066 CLR 2.0, 7.2.20072.1074 CLR 2.0, 7.3.20073.1048 CLR 2.0, 8.1.20081.1006 CLR 2.0, 8.1.20081.1006 CLR 3.5
To all: Be sure to contact out support team (www.infragistics.com/gethelp) to get "linked" to this and any other bug that you may encounter. That will get you on the autonotify list for all changes in bug status.
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
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.