Hi, have used a memory profiler on a project which has revealed a memory leak for my app. The issue is that when I remove nodes from the UltraWinTree references to these removed nodes are still being held in the private visibleNodes variable of type VisibleNodesManager within the UltraWinTree. Is there a way for me to 'refresh' this list? I cannot find any method which might help in this regard. Or, could anyone suggest a workaround for this?
I am using version 6.1.20061.1069 of the UltraWinTree.
Many thanks in advance.
Pete.
Hi Pete,
I took a look at the code and as far as I can tell, there's no way to work around this. But the issue was fixed around 2009 (in v8.3 and up). So if you update the latest version (2016.1), this should no longer be a problem.
I've looked more closely at my Infragistics account downloads and I've access to 2009 Vol 2, which I've upgraded my project to. This gives me version 9.2.20092.1003 of the UltraWinTree.
BUT, the same memory leak problem STILL exists in this version, despite you saying it was fixed in v8.3 and up!!!???
Can you please offer some help or a solution?
Hi Mike,
Sorry for the delay in replying - time differences!
I've now had the chance to use a different Memory profiler, which enables me to force garbage collections between snapshots of memory. This new profiler still shows the same problem, despite the collections.
Maybe I'm not expressing myself accurately, but I feel strongly there is a problem here. It's very unlikely 2 different packages pointing to the same cause of the memory leak are wrong.
Is there a way I can email you screen shots containing the chain of dependencies, as I'd rather not post everything here?
Cheers
Could I ask you to take another look at the code base. Specifically, at the .Key property of the generic Entry<UltraTreeNode , TreeNodeUIElement> within the entries generic dictionary.
This is the thing that's holding onto a reference of the UltraTreeNode that's been removed from the Tree.
Many thanks for all your help.
The Key property is not on an Infragistics object. That's part of the DotNet Framework and how it keeps track of items in a Dictionary<>. Once the collection is cleared (and it's cleared essentially every time something changed in the control), there nothing holding a reference to that node any more.
If you check the memory usage at that time, you might see that node in memory, because it has not been (and cannot be) explicitly disposed. But once the Garbage collector collects, it will be cleaned up, since nothing is holding a reference to it any more. Hence why I suspect you are simply not explicitly garbage collecting in your testing.
Screen shots wouldn't really help here, but if you are garbage collecting and there's still an issue, then we would need to be able reproduce the problem in order to debug it and figure out what's going on. Can you create a small sample project that demonstrates the leak? If it truly is a bug in the control, then this should simply be a matter of creating a tree with some nodes, taking a snapshot, then removing some nodes, and taking another snapshot and comparing the two.
Just to be sure, I tried this out in a very simple case, and even without explicitly doing garbage collection, I don't see any problem. I am attaching my sample here so you can try it out.
All I did was I ran the sample and took a snapshot using Ants Memory Profiler. Then I click the button a few times. Then took another snapshot.
There is an increase in the instances of some classes like object and StringFormat, but nothing related to the tree.
I did my testing with v9.2 with the latest service release, so it's possible there are some fixes I have that you don't. You could correct that by getting the latest SR for 9.2, but when I looked at the code, I didn't see anything in there that would have had any effect on this behavior.
See if you get the same leak with my sample. If not, then the issue is in something your application is doing that mine is not. If you do get the same leak, then this must be a difference between the version you are using and the one I am using so getting the latest SR should fix it.
Pete said:I am aware .KEY is a property on a .NET framework class, but it is being used within an Infragistics type. I only mentioned it as additional information as to the whereabouts of the reference within said type that was causing the issue.
Yeah, that part is pretty clear. The Dictionary is using the node as a key and storing the UIElement for that node. This is a performance optimization so we can easily find the UIElement for the node.
But since the Dictionary is cleared often, I don't see any way that this could cause a memory leak.
Anyway, I'm eager to see what happens with my sample on your machine.
Mike
Thanks for your replies.
I am aware .KEY is a property on a .NET framework class, but it is being used within an Infragistics type. I only mentioned it as additional information as to the whereabouts of the reference within said type that was causing the issue.
ANTS is the same profiler I am using so that will keep things even between our tests too.
I'll get back to you with my findings.