Hello,
Looks like your XamTabControl is leaking memory. If I replace the XamTabControl with a regular TabControl memoy is released after I force a Garbage Collection. I have the following simpe XAML:
<UserControl x:Class="ControlsLibrary.wpf.TabUserControl" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:igWindows="http://infragistics.com/Windows" > <Grid> <igWindows:XamTabControl> </igWindows:XamTabControl> <!--<TabControl> </TabControl>--> </Grid></UserControl>
with the following code behind:
public partial class TabUserControl : UserControl { //Mailbox parent; //UserControl activeContent; public byte[ myMemory = new byte[50 * 1024 * 1024]; public TabUserControl() : this(null, null, -1) { InitializeComponent(); } }
Please try this and advise.
Klaus
The snippet you provided doesn't seem like it would compile and it doesn't show how the usercontrol was being used but if you can provide a sample I'll take a look.
public partial class TabUserControl : UserControl { //Mailbox parent; //UserControl activeContent; public byte[ myMemory = new byte[50 * 1024 * 1024]; public TabUserControl() { InitializeComponent(); } }
Create an instance of TabUserControl and add to a Window.
Open and close the Window, then force a GC. Observe that the 50M allocated is not released.
Instead of XamTabControl, use WPF's native TabControl. Perform the same operations and observe that memory is released after you force a GC.
I ran this (after fixing the the myMemory field declaration - missing the ]) through a memory profiler (I used the Scitech one) and neither the UserControl, XamTabControl nor the Window that contained these were rooted in memory so I don't see a memory leak. Again perhaps there is something more occuring in the project in which you are seeing the problem that is contributing to the issue. If you would like us to look into it I would recommend providing a sample that demonstrates the problem to the support group.
Hi,
Its been a month that i got a reply about hot fix.. any update on this ???
Again a memory profiler provides a more accurate depiction of what is actually going on in the memory usage - what elements remain in memory, etc. With regards to xamTabControl there was recently an issue reported regarding a problem with the TabItemPanel it uses by default that could cause a removed tab to remain in memory. That specific issue has been addressed and should be in the next hotfix (available next week I believe).
It may be misleading but it is the clear case of memory leak because it is 100% slow down the entire application performance. This what we have found from our side. If we replace with normal tab control this problem doesnt exists. This also proves some problem in the xamtab control.
The best sample application is the xamFeatureBrowser comming along with the installables. Just open Add/Remove Tabs under xamTabControl. When it opens the size used is 68 K add 50 tabs three times memory grows to 76 K and click remove all tabs then memory never comes down.
I'm not sure the memory profiler is not finding the issue, but from our experiance with xamtabcontrol is the clear case of memory leak.
Please advice from your side is there any issue beuase we are coding exactly the way is mentioned in the xamFeatureBrowser.
Thanks for your reply,
Senthil
Actually using a memory profiler is really better for determing if there really is a leak. The task manager information can be misleading. You can find more information about that searching on the internet - e.g. http://www.itwriting.com/dotnetmem.php). Can you provide a sample that demonstrates a memory leak?
Dear Smith,
Same problem is occuring for me, no need to test using memory profiler instead just see in the task bar memory usage it wont reduce at all.. I have almost 100's tabs can be opened in that case it is creating serious issue.
If problem exisits we dont have anyother option other than use some other controls. please suggest
Thanks,