Where multiple memory leaks were encountered during WPF application development using Openexpressapp , a memory leak problem was approached in the previous article "WPF unknown memory leak reason, hair is white a few root", This article will share with you how to solve this problem.
Problem Finding
When users use the product, they report a memory overflow error when they use it for a long time, and start looking for memory leaks. A DataGrid memory leak problem is described in "WPF-.net 4.0 resolves a memory leak when a DataGrid is grouped ," which is mainly about the problem that the object is still not released after the module is closed.
Problem Solving
This issue was previously made by another colleague using ANTS Memory Profiler 5 to view the location to be button caused, but the cause is unknown. Because the memory leak is not a small problem, I decided to take a look this week.
continue to find reason
Use the ANTS memory Profiler 5 to see the problem with the leak, and find the problem is on the button, but I can't figure out why it's on the button, especially with the WPF DependencyObject stuff, It's not easy to find out if you want to understand. Since Monday I have had time to position this problem, but today I still have no clue: ( So I started looking for other ways.
- Use other memory leak tools to see
Google on the internet a bit of memory leak tool, click on one, download the SciTech Memory Profiler Trial version, after the new project ran a program, close the module after taking a snapshot, in the type Details tab Enter the Projectlist class library, showing that its path and path are the same:
But this tool is good to see the call stack (maybe ANTS Memory Profiler also has this feature, just I don't know), switch several classes to view the stack and find the class library in Openexpressapp, happy, such as:
It can be seen that the code in the Buttoncommand.setcommand caused the leak.
- This Morning Post "WPF-.net 4.0 resolves a memory leak when the DataGrid is grouped "
Thank you a lot of friends immediately to my reply, which Li Yongjing must be experienced master, through one of my diagram can guess the problem, I think he must have been troubled by this. His reply was this:
LZ is not with Dependencypropertydescriptor.fromproperty
This gets the attribute and then uses addvaluechanged to add the delegate to track the change of the property value, and finally to remove the unload.
This is speculation, no specific code is difficult to analyze.
Solutions
Through the above lookup, the basic positioning may appear in the Tracking property value changes in the addvaluechanged, view the project code, found that it is true that the
So Google search "PropertyDescriptor addvaluechanged leak", saw an article in this related blog:propertydescriptor addvaluechanged Alternative. Read this article, know is due to the event strong reference, the blog also proposed a solution, is to establish a Propertychangenotifier class, through the weak reference object to establish the property value change event binding, Specific code and instructions refer to this Bolg can PropertyDescriptor addvaluechanged alternative, I will no longer detail.
The problem is fixed, and the solution is Then began to move the knife to modify the problem: full-text Search Dependencypropertydescriptor.fromproperty, found that there are two uses, are referenced in the Openexpressapp external code, one is the Buttoncommand of the package command, a A viewlayoutmanager that restricts the listview width, the code changes as follows: (You can also solve by WeakEventManager )
Memory leak, use Propertychangenotifier
Dependencypropertydescriptor.fromproperty (
Button.isenabledproperty,
typeof (Button)). AddValueChanged (button, buttonisenabledchanged);
Propertychangenotifier notifier = new Propertychangenotifier (Button, "isenabled");
Notifier. ValueChanged + = new EventHandler (buttonisenabledchanged);
The code changes and then ran the test, found that the object has been unable to find, and finally solved the problem:) began to look for other memory leak problems, but now there areSciTech Memory ProfilerShould be able to locate faster.
Review
- The event strong reference is. NET memory leaks often occur due to code not paying attention to the problems caused by
Leak Description |
Developer Error |
Improper use of Event handlers |
X |
Improper use of Data Binding |
X |
Improper use of Command Binding |
X |
Improper use of Static Event handlers |
X |
- Set task Timebox, not resolved at the time, you can try other tool methods: such as the use of other tools; seek the help of experienced enthusiastic people
Related blog
WPF-.net 4.0 resolves a memory leak when a DataGrid is grouped
WPF unknown memory leak reason, hair is white a few root
PF unknown memory leak has been resolved, no white hair (turn)