Question

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?

Answer 1

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.