http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Erik, Ayende - the documentation above actually has Erik's quote under the section describing .NET framework 1.0 and 1.1 behaviour. In other words the quote describes the pre-Framework 2.0 behaviour.http://ayende.com/4827/answer-stopping-the-leaks#comment14http://ayende.com/4827/answer-stopping-the-leaks#comment14Sat, 14 May 2011 17:03:26 GMTI always thought managed references were not supposed to be used in the finalizer. http://ayende.com/4827/answer-stopping-the-leaks#comment13http://ayende.com/4827/answer-stopping-the-leaks#comment13Tue, 10 May 2011 11:03:12 GMTOh dear, Blinded by my lack of morning tea. What a buffoon! http://ayende.com/4827/answer-stopping-the-leaks#comment12http://ayende.com/4827/answer-stopping-the-leaks#comment12Tue, 03 May 2011 09:15:56 GMTRoja, That isn't called in the constructor, BufferTracker doesn't HAVE a ctor. http://ayende.com/4827/answer-stopping-the-leaks#comment11http://ayende.com/4827/answer-stopping-the-leaks#comment11Tue, 03 May 2011 09:03:23 GMTAyende, Forgive my ignorance but could you explain the reasoning / need for calling GC.ReRegisterForFinalize(this) within the BufferTracker constructor? As far as I can tell there is no way for SuppressFinalize to have been called on the object prior to it's construction and thus, as a finalizer is implemented in the class, would expect to find the newly created object on the finalization queue? http://ayende.com/4827/answer-stopping-the-leaks#comment10http://ayende.com/4827/answer-stopping-the-leaks#comment10Tue, 03 May 2011 08:54:40 GMTErik, The documentation is wrong. Try calling GC.WaitForPendingFinalizers(); http://ayende.com/4827/answer-stopping-the-leaks#comment9http://ayende.com/4827/answer-stopping-the-leaks#comment9Sun, 01 May 2011 13:19:14 GMTAccording to this: [msdn.microsoft.com/en-us/library/ms228965.aspx](http://msdn.microsoft.com/en-us/library/ms228965.aspx) "There is no such thing as an unhandled exception on the finalizer thread. When a finalizer throws an exception that it does not handle, the runtime prints the exception stack trace to the console and then allows the finalizer thread to resume running finalizers." It appears that this is a change in .NET4. I could not reproduce appropriately failing conditions in a unit test either -- I could not get the expected exception thrown, even with GC.Collect's thrown in. http://ayende.com/4827/answer-stopping-the-leaks#comment8http://ayende.com/4827/answer-stopping-the-leaks#comment8Sun, 01 May 2011 13:17:16 GMTErik, Unhandled exception in the finalizer will cause a crash, yes. An error would be outputted to the console and the application will terminate. http://ayende.com/4827/answer-stopping-the-leaks#comment7http://ayende.com/4827/answer-stopping-the-leaks#comment7Sun, 01 May 2011 12:36:54 GMTI don't think your comment is entirely accurate: "// note that disposing the pool before returning all of the buffers will cause a crash"... There is no such thing as an unhandled exception in the finalizer -- all that will happen is an error message will be output to the console. If that is true, how is this protecting us from leaked buffers? I hadn't heard of ConditionalWeakTable before. That is amazing and extremely useful! http://ayende.com/4827/answer-stopping-the-leaks#comment6http://ayende.com/4827/answer-stopping-the-leaks#comment6Sun, 01 May 2011 12:29:25 GMTThis sort of approach reminds me of what Scott Bilas was calling Assertive Finalizers: [http://scottbilas.com/blog/assertive-finalizers/](http://scottbilas.com/blog/assertive-finalizers/) Anyway, I'm surprised to see BufferPool have a Dispose method but not inherit the IDisposable interface - that would make it easier to use and have code analysis tools which verify that Dispose is called properly to work better. (Basically, when about to implement an interface like Dispose, I would recommend starting with typing the ": IDisposable", right-click and let it make the method for you, then fill in the code. As we just saw, the other way around can result in forgetting to add an interface which properly describes an important aspect of the class). http://ayende.com/4827/answer-stopping-the-leaks#comment5http://ayende.com/4827/answer-stopping-the-leaks#comment5Sat, 30 Apr 2011 20:49:26 GMT@Ryan: ConditionalWeakTable is new in .NET 4.0. In fact, it is impossible to correctly implement the "connected properties" in .NET 3.5, since a special GC feature (ephemerons; new in .NET 4.0) is required to avoid leaking memory when the value references the key. Unfortunately it seems that the WPF team at MS has't heard of ConditionalWeakTable yet - this memory leak in WPF still exists: [http://support.microsoft.com/kb/938416/en-us](http://support.microsoft.com/kb/938416/en-us)http://ayende.com/4827/answer-stopping-the-leaks#comment4http://ayende.com/4827/answer-stopping-the-leaks#comment4Sat, 30 Apr 2011 18:15:37 GMTAre you sure you want to instantiate StackTrace for this task? Have you ever notice how slow is "new StackTrace()"? http://ayende.com/4827/answer-stopping-the-leaks#comment3http://ayende.com/4827/answer-stopping-the-leaks#comment3Sat, 30 Apr 2011 15:49:15 GMTHow did I not notice ConditionalWeakTable before? I always felt a need for such behavior when extension methods were introduced to C# ... Anyhow I did some googling and found someone had implemented my idea already, isnt that wonderful? :) [http://connectedproperties.codeplex.com/](http://connectedproperties.codeplex.com/) // Ryan http://ayende.com/4827/answer-stopping-the-leaks#comment2http://ayende.com/4827/answer-stopping-the-leaks#comment2Sat, 30 Apr 2011 12:23:25 GMTIts most simple description is that the values have exactly the same lifetime as the keys. It is meant to attach additional data to existing, not extensible objects. http://ayende.com/4827/answer-stopping-the-leaks#comment1http://ayende.com/4827/answer-stopping-the-leaks#comment1Sat, 30 Apr 2011 11:54:49 GMT