The Syncfusion native Blazor components library offers 70+ UI and Data Viz web controls that are responsive and lightweight for building modern web apps.
.NET PDF framework is a high-performance and comprehensive library used to create, read, merge, split, secure, edit, view, and review PDF files in C#/VB.NET.
I have been using Syncfusion Essential Grid (v 1.5.2 I believe).
Running my application through a memory profiler I have encountered a few memory leaks. Two of these I have tracked down to minor problems in the Syncfusion source code.
There are three events still attached to disposed instances of GridControl.
The first two are is in
Syncfusion.Windows.Forms.Grid.GridControlBase.UnwireModel().
This method appears to be used to detach event handlers prior to Disposal. One of the event handlers "Model.InvalidateRequestRange" is added instead of removed. (There are 2 handlers attached, instead of zero.) I think this is a simple case of a "+=" instead of an intended "-=" in the source code.
This added event appears to prevent the Garbage collector from collecting the grid.
Interestingly enough, this only causes problems if the application explictly calls Dispose() on the GridControl for the following reasons:
First, note that the .NET garbage collector is really cr*ppy and does not always collect objects that have events pointing to them, even if there are no root paths to those objects. This means that such items need to have these event handlers explicitly removed so that they become elligible for garbage collection.
Second, note that if the .NET garbage collector queues an object for collection, it calls IDisposable.Dispose() on that object if necessary and then collects that object.
Because of this, if the garbage collector collects the GridControl, the extra event (added during disposal) does not prevent collection as the object is already queued for collection.
However, if you explictly call Dispose() on the Syncfusion GridControl, the GridControl is never collected because the event that is added during disposal prevents garbage collection.
Lastly, I found that in Syncfusion/Shared/Scrolling/ScrollControl, an event handler is attached to "imm.DragScroll"
This event handler appears to never be detached during disposal and thus may also contribute to memory leaks.
ADAdministrator Syncfusion Team June 24, 2005 08:05 AM UTC
Thank you for the details.
Yes, 1.5.x had some memory leaks.
Both problems you mentioned have been corrected in our later releases. They are not in 3.2.1.0.