http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Daniel, Yes, the WPF team is aware of this issue. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment34http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment34Sun, 04 Oct 2009 20:38:38 GMTThis is not the "by design" scenario described in KB 938416. The condition "Object X contains a direct reference or an indirect reference to the target of the data-binding operation." is not fulfilled in this example. This looks like a .NET Bug to me. I've tried .NET 4.0 Beta 1 and .NET 4.0 Sept. LCTP; this memory leak is still present in both of them. Did anyone submit a bug report to Microsoft? http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment33http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment33Sun, 04 Oct 2009 12:38:16 GMTDigging in I discovered that the Binding System doesn't deregister the listener for the "Name" property when you notify that Data has changed. It's definitely a bug and it has to do with the way the binding system looks at the binding in question. When you notify that Data has changed, rather than deregistering the existing bindings further down the tree (in this case the Name binding on your Textblock) and reusing the elements it appears that an entirely new set of elements are created. Unfortunately, the Textblock never gets the opportunity to deregister its binding. Now if you made Data an observable collection (necessitates making your anonymous type into a full class) and made the collection raise a CollectionChanged event (e.g. Data[0]=Data[0]), everything works just fine. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment32http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment32Thu, 01 Oct 2009 20:06:37 GMTThe problem is that the weak references do not get unrooted. The trade off is that instead of rooting a FrameworkElement (which would kill your memory a lot quicker) you're rooting a WeakEvent object which despite having a much smaller memory footprint...still has one. It appears that the PropertyChangedEventManager has a function that allows a WeakEventListener to be deregistered...but it doesn't get called by the framework. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment31http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment31Thu, 01 Oct 2009 18:19:45 GMTI had similar problems with some 1.1 code that was upgraded to 3.5. In 1.1, Garbage collection worked fine for a particular scenario, but when it was upgraded to 3.5 it seemed that the Application, while not throwing any sort of exception, was slowly using more and more memory. Change the code to read: private void Timer_Tick(object sender, EventArgs e) { if (count++ % 100 == 0) { TestModel.MinimizeMemory(); //GC.Collect(2, GCCollectionMode.Forced); Console.WriteLine("{0:#,#}", Process.GetCurrentProcess().WorkingSet64); } PropertyChanged(this, new PropertyChangedEventArgs("Data")); } public static void MinimizeMemory() { GC.Collect(GC.MaxGeneration); GC.WaitForPendingFinalizers(); SetProcessWorkingSetSize(Process.GetCurrentProcess().Handle, (UIntPtr)0xFFFFFFFF, (UIntPtr)0xFFFFFFFF); IntPtr heap = GetProcessHeap(); if (HeapLock(heap)) { try { if (HeapCompact(heap, 0) == 0) { // error condition ignored } } finally { HeapUnlock(heap); } } } [DllImport("kernel32.dll")] [return: MarshalAs(UnmanagedType.Bool)] internal static extern bool SetProcessWorkingSetSize(IntPtr process, UIntPtr minimumWorkingSetSize, UIntPtr maximumWorkingSetSize); [DllImport("kernel32.dll", SetLastError = true)] internal static extern IntPtr GetProcessHeap(); [DllImport("kernel32.dll")] [return: MarshalAs(UnmanagedType.Bool)] internal static extern bool HeapLock(IntPtr heap); [DllImport("kernel32.dll")] internal static extern uint HeapCompact(IntPtr heap, uint flags); [DllImport("kernel32.dll")] [return: MarshalAs(UnmanagedType.Bool)] internal static extern bool HeapUnlock(IntPtr heap); Will"fix" the problem in the sense that it will stop the memory leak. It doesn't do a great job explaining it, unless the GC in 1.1 used to compact the process heap and 3.5 doesn't. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment30http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment30Thu, 01 Oct 2009 16:27:42 GMTCould it be the Templates not being recycled that is the problem? In SP1 they added the VirtualizingStackPanel.VirtualizationMode="Recycling" which is set to "Standard" default. I have no idea, why it would hang on to the old templates, tho. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment29http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment29Thu, 01 Oct 2009 12:07:46 GMT@Ryan Heath: Yep then this is the issue it talked about above. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment28http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment28Thu, 01 Oct 2009 11:49:52 GMTInteresting, changing the code to: public class MyModel : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged = delegate { }; public string Name { get; set; } } ... new MyModel{Name = "Ayende"}, ... Seems to keep the mem usage low ... // Ryan http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment27http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment27Thu, 01 Oct 2009 10:23:42 GMTalwin, Yes, the problem persist for named classes as well. And there aren't live instances of the data class in memory, only the weak ref stuff http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment26http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment26Thu, 01 Oct 2009 09:10:12 GMTct, You'll see the same behavior in any Windows app. Windows reduce the working set of an app when it is minimized http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment25http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment25Thu, 01 Oct 2009 09:08:22 GMTThe problem is that you return an array of objects that are not implement INotifyPropertyChanged and then Databind to property's of this object. You can read more about here: [support.microsoft.com/](http://support.microsoft.com/?scid=kb%3Ben-us%3B938416&x=11&y=11)http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment24http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment24Thu, 01 Oct 2009 06:47:31 GMTOh and if you return a 'real' (I mean named) class from Data, you can more easily debug the heap to find instances of that class and references to it. public IEnumerable Data { get { return new DataList() { new DataItem {Name = "Ayende"}; } } Then try to find references to DataList and DataItem with dumpheap or something, not sure how to do this though. Maybe this can help: [blogs.microsoft.co.il/.../...tancesof-lt-t-gt.aspx](http://blogs.microsoft.co.il/blogs/sasha/archive/2009/08/17/gc-helper-for-obtaining-live-instances-of-a-type-or-how-i-implemented-gc-getaliveinstancesof-lt-t-gt.aspx) [blogs.microsoft.co.il/.../...emo-2-and-demo-3.aspx](http://blogs.microsoft.co.il/blogs/sasha/archive/2008/04/08/next-generation-production-debugging-demo-2-and-demo-3.aspx)http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment23http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment23Thu, 01 Oct 2009 06:27:06 GMTDoes the memory go up when you keep returning the same object from the Data property? BTW have you asked this on stack overflow? Never know if someone knows the answer there. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment22http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment22Thu, 01 Oct 2009 06:17:01 GMTTracing with Dot Trace it is obvious that WeakReference object will never gets disposed, because their number grow continuosly. The problem maybe is due to the fact that the view model exposes data property ad simple property, and not as a dependencyproperty, as ususal. I did a very quick try, but if you make your model inherit from dependenyobject, transform the data property in a DependencyProperty all those weak references seems to be gone away. Alk. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment21http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment21Thu, 01 Oct 2009 06:16:04 GMTI strongly believe if some WPF core component was broken, VS10 in WPF wouldn't be possible. As we can see, it just is, so it is safe to presume you must be doing something wrong. Have you tried MSDN forums? http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment20http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment20Thu, 01 Oct 2009 05:58:57 GMTI remember colleagues talking about a problem when bindind real time data to a TextBox. The undo feature was accumulating all previous values, even if the TextBox is in readonly mode. They had to disable undo on the textbox to fix the leak. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment19http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment19Thu, 01 Oct 2009 05:51:48 GMTI think you are guilty of thinking that automated tests and paying attention to infractructure design lead to error free applications. Now you have been reprimanded for forgetting about Microsoft's hard work. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment18http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment18Thu, 01 Oct 2009 05:05:32 GMTIf I minimize the WPF app the memory goes down just fine. Restoring and it grows. So something about minimizing causes it to release the memory. Sounds like it might be something MS is holding onto internally for drawing isn't cleared unless it has nothing to draw (ie. when minimized perhaps?) http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment17http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment17Thu, 01 Oct 2009 03:07:58 GMTI'm not a wpf programmer, but from what I have seen wpf uses a lot of static variables and the weakreference seems to indicate that wpf might be storing weakreferences in a static variable somewhere. Although the target of the weak reference is collected the weakreference object will hand around in some static list somewhere where some background thread will periodically remove weakreferences that no longer point to a valid object. But, in your case probably not nearly often enough. Your job if you choose to accept it is to find out where and if you can force a cleanup.. The Weakeventmanager class looks promising, but purge does not appear to be public or static. Digging around in reflector a bit it looks like there is a singleton weakeventtable that is cleaned up when idle. the class is internal (of course), but you could try calling WeakEventTable.CurrentWeakEventTable.Cleanup through private reflection. If that works then maybe more digging will reveal some publicly accessible method that could force a cleanup. I could be completely wrong on this but worth a try. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment16http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment16Thu, 01 Oct 2009 02:55:44 GMTDuring the test, checks assert that PropertyChanged only has one listener registered? (not getting caught up registering a new listener, or maybe something with how it's hooked up?) http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment15http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment15Thu, 01 Oct 2009 02:46:01 GMT!dumpheap -stat http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment14http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment14Thu, 01 Oct 2009 02:07:20 GMTWhat commands did you use to extract that information from the dump? I'm also debugging a CLR memory leak, and info about what kind of objects are taking up memory would be incredibly helpful http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment13http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment13Thu, 01 Oct 2009 01:50:15 GMTThe thing is, you see quite a few WPF programs slowly go up in memory - so it could be a common thing. That or it's an easy thing to blame it on. I remember Witty always slowly took more memory, even if I cleared the tweets in it. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment12http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment12Thu, 01 Oct 2009 01:08:36 GMTMy guess is you're running into this issue: [http://support.microsoft.com/kb/938416](http://support.microsoft.com/kb/938416) But changing {Binding Name} to {Binding Name, Mode=OneTime} doesn't appear to resolve it. (It definitely slows it down, though.) http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment11http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment11Thu, 01 Oct 2009 00:58:43 GMTOh, right, The Pragmatic Programmer. Duh. *sigh* http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment10http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment10Thu, 01 Oct 2009 00:56:25 GMTVery interesting We're getting this EXACT same issue with a different app but using the same bits you're talking about. WPF, Timers, Event Handlers, and INotifyPropertyChanged. We also have a bunch of Observable collections of types that implement INotifyPropertyChanged. I had started digging down, but hadn't gotten further than getting the memory dump and doing some preliminary poking around the codebase. I figured it was us doing something wrong. Good to see others having the same issue. Looking forward to seeing the resolution to this though. Also - Tobin, the reference about "select being broken" is from a fairly common bit of lore that goes along the lines of "If you think SELECT is broken, then you're doing something wrong". i.e If you think something fundamental and well used by everyone, then there's a pretty damn good chance that you're using it wrong. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment9http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment9Thu, 01 Oct 2009 00:55:14 GMTYeah, I can't figure out why this is happening, though. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment8http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment8Thu, 01 Oct 2009 00:52:10 GMTAh, got you now, damn in-jokes :) It looks like the binding isn't releasing the old values when the OnPropertyChanged is being fired and refreshing the data? http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment7http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment7Thu, 01 Oct 2009 00:49:11 GMTTobin, It is a reference to The Pragmatic Programmer: select() isn't broken. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment6http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment6Thu, 01 Oct 2009 00:45:14 GMTErik, Manual code review, checking gc roots, etc. Look for debugging memory leaks, you'll see a lot of articles about how to figure that out. http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment5http://ayende.com/4221/sometimes-it-looks-like-select-is-broken-a-wpf-memory-leak#comment5Thu, 01 Oct 2009 00:44:23 GMT