Brian Donahue wrote:It's hard to tell what's happening with your results from this information, but I'd assume some of your datarow objects are being referenced from somewhere else than the parent DataTable.
Brian Donahue wrote:Hi,
For the .NET Garbage Collector, it's all about whether or not another object is holding a reference to the DataRow. The object's lineage is not as important. So for instance if you have a DataRow as part of a DataTable and an event handler references the DataRow, you can dispose the DataTable and the Garbage Collector will still leave the DataRow because something else is referencing it.
AndrewH wrote:If you want to explore a more complicated relationship between objects, the tool to use is probably the instance categoriser in all references mode (the mode selector is in the upper right of the screen): you can either start with the DataSet class and expand to the right to see the DataTables that it is referencing, or start at the DataTable class and expand to the left to see the DataSets that are referenced by them.
In the class list, you might find the 'Referenced By DataSet' filter useful (to see all of the objects that are connected somehow to a DataSet), and maybe also the 'Kept in memory exclusively by DataSet' filter (which gives you the set of objects that are only in memory because of DataSet objects)
AndrewH wrote:If you want to find leaked DataTables, a good combination of filters might be to use is 'objects that implement DataTable' and 'Never Referenced By DataSet' (this will give you all of the DataTables that are still in memory but no longer have an active DataSet object associated with them)
Brian Donahue wrote:The objects are in memory because garbage collection is not cleaning them up because something has a reference to them. The retention graph should show you those references.
Users browsing this forum: No registered users and 0 guests