Reputation: 9044
I am trying to pro-actively ensure I am not causing memory leaks in my code by keeping an extra weak reference to an object, and checking it is no longer active when it should be released (this is conditional code so it only runs when I am testing).
To simply reproduce the effect I am seeing, create a new WPF Application and put a Button on the main window. Create another window, and put a TextBox on it. In the click handler for the button, put the following code:
Window1 w = new Window1();
WeakReference weak = new WeakReference(w);
w.ShowDialog();
w = null;
// Equivalent to Application.DoEvents() just in case...
Application.Current.Dispatcher.Invoke(DispatcherPriority.Background, new Action(delegate { }));
GC.Collect();
GC.WaitForPendingFinalizers();
if (weak.Target != null)
MessageBox.Show("Memory Leak");
When you run this, click on the button and when the window displays, just click on the 'x' to close it and nothing happens - all good. Now do the same thing, but when the window displays, click into the TextBox and then click on 'x'. I get the "Memory Leak" message every time.
Ants Profiler shows System.Windows.Documents.TextEditor has a reference to the TextBox (which presumably gets set up only if you focus the TextBox), and the TextBox has a reference to the window. Its not a real memory leak because if you do the process multiple times, previous windows get collected, just not the latest. However, it means I cannot write tests that confirm memory is not leaking.
Am I the only person wanting this level of assurance, or is there another way?
Upvotes: 4
Views: 3525
Reputation: 103
try with DispatcherPriority.ContextIdle
Dispatcher.CurrentDispatcher.Invoke( DispatcherPriority.ContextIdle, new System.Action(delegate { }));
Upvotes: 0
Reputation: 178660
I think some people have missed the point of your question. You're not trying to force GC's hand, but rather preemptively discover any memory leaks, and for that I applaud you.
In this particular case, it appears as though TextEditor
(which is internal
) is adding event handlers and has not yet had a chance to detach when your check runs. Have you tried explicitly shifting focus out of the closed window before pumping the dispatcher?
I think you will continue to run into these kind of issues if you attempt to do these tests in your application proper, rather than in the more controlled environment of integration tests, so perhaps you need to re-think your approach.
Upvotes: 2
Reputation: 184534
Windows are not just managed by your code but also by some WPF classes like Application
. Calling Collect
does not guarantee or prove anything, the window does get collected eventually.
Upvotes: 0
Reputation: 2347
If previous instances get collected, it's not a memory leak. The garbage collector doesn't always take the most recent items, and it's by design. If you try to second-guess it you'll likely run into problems.
In a real memory leak items will accumulate without ever being reclaimed. That's something best detected using the profiler.
Upvotes: 0