I am currently attempting to deal with an issue with releasing a FlowDocument resources. I am loading an rtf file and putting it into a FlowDocument with TextRange.Load. I n
If I've confirmed that there's a memory leak, here's what I would do to debug the problem.
.loadby sos mscorwks
!dumpheap -type FlowDocument
Type !gcroot <value of first column>
That should show you who's holding on to the reference.
GC.Collect()
by itself won't collect everything, you need to run:
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Also, I've found the runtime doesn't always release collected memory right away, you should check the actual heap size instead of relying on task manager.
FlowDocument uses System.Windows.Threading.Dispatcher to free all resources. It doesn't use finalizers because finalizers will block current thread until all resources will be free. So the user may see some UI freezings and so on. Dispatchers are running in background thread and have less impact on the UI.
So calling GC.WaitForPendingFinalizers(); has no influence on this. You just need to add some code to wait and allow Dispatchers to finish their work. Just try to add something like Thread.CurrentThread.Sleep(2000 /* 2 secs */);
EDIT: It seems to me that you found this problem during debugging of some application. I wrote the following very simple test case (console program):
static void Main(string[] args)
{
Console.WriteLine("press enter to start");
Console.ReadLine();
var path = "c:\\1.rtf";
for (var i = 0; i < 20; i++)
{
using (var stream = new FileStream(path, FileMode.Open))
{
var document = new FlowDocument();
var range = new TextRange(document.ContentStart, document.ContentEnd);
range.Load(stream, DataFormats.Rtf);
}
}
Console.WriteLine("press enter to run GC.");
Console.ReadLine();
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine("GC has finished .");
Console.ReadLine();
}
I've tried to reproduce the problem. I run it several times and it was working perfectly - there were no leaks (about 3,2Kb all of the time and 36 handles). I couldn't reproduce it until I run this program in debug mode in the VS (just f5 instead of ctrl+f5). I received 20,5Kb at the beginning, 31,7Kb after loading and before GC and 31Kb after GC. It looks similar to your results.
So, could you please try to reproduce this problem running in release mode not under the VS?
Make sure that the Parent of the FlowDocument isn't hanging around, see here. "Instantiating a FlowDocument automatically spawns a parent FlowDocumentPageViewer that hosts the content." If that control is hanging around it could be the source of your problem.
We had a similar problem in which we were creating flow document in different thread, i noticed in memory profiler that objects were still there.
So far as i know, as described in this link
"When a FlowDocument is created, relatively expensive formatting context objects are also created for it in its StructuralCache. When you create multiple FlowDocs in a tight loop, a StructuralCache is created for each FlowDoc. Let's you called Gc.Collect at the end of the loop, hoping to recover some memory. StructuralCache has a finalizer releases this formatting context, but not immediately. The finalizer effectively schedules an operation to release contexts at DispatcherPriority.Background."
So until the dispatcher operations are completed, Flow document will be in memory. So the idea is to complete the dispatcher operations.
If you are in a thread in which Dispatcher is currently running then try code below, it will force all the operations in queue to be completed, as SystemIdle is the lowest priority:
Dispatcher.CurrentDispatcher.Invoke(DispatcherPriority.SystemIdle,
new DispatcherOperationCallback(delegate { return null; }), null);
If you are in a thread in which Dispatcher is not running, as in my case only single flow document was created in thread, so i tried something like:
var dispatcher = Dispatcher.CurrentDispatcher;
dispatcher.BeginInvokeShutdown(DispatcherPriority.SystemIdle);
Dispatcher.Run();
this will queue a shut down at very end and then will run the dispatcher to clean the FlowDocument and then in end it will shut down the dispatcher.
Consider releasing that file handle. Also consider using the "using" statement instead of calling IDisposable.Dispose (no pun intended).