Troubleshooting Dispose Related Leaks

Recently the SPDisposeCheck utility was announced by Paul Andrew from the Microsoft SharePoint Product Group which was published 1/29/09 here. This command line utility will help scan your custom MOSS and WSS 3.0 .NET assemblies (MSIL not your original source code) automatically scanning for the guidance listed on this blog post. SPDisposeCheck will produce a summary report calling your attention to areas in your code you that you need to closely examine for possible Dispose() related leaks. After you have completed your initial scan with SPDisposeCheck you should examine the SharePoint ULS logs to help further verify that no Dispose() edge cases will be introduced into your shared development, test, and production environments. Stefan Goßner (Microsoft Support Escalation Engineer) has created guidance on using the ULS logs to Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007 . See also Stefan’s Disposing SPWeb and SPSite objects for additional info. For advanced troubleshooting you can ($) contact Microsoft Support or if you have a Premier Contract you can engage Microsoft Premier Support’s Developer Advisory Services (DAS) or Premier Field Engineering (PFE) resources for advanced troubleshooting, debugging, and proactive advisory services including custom code reviews.

Try / finally using() Dispose()

ake certain that the objects listed here which need to be properly Disposed by your application code is wrapped within a using(), try/finally, or try/catch/finally block. Failure to do so can lead to unexpected memory leaks as there is no other way to guarantee that your Dispose will be reached in the event of an exception. See my updated guidance here.

Dispose Patterns

When writing customized SharePoint code you need to be aware of the scope and context of each SPSite, SPWeb objects lifetime. When objects are created and destroyed in the same method or iteration scope (foreach or do/while loop) they are the easiest to clean handle. Things become more complex to review when developers create objects in one method and dispose in another. Areas to be aware of are assigning objects to class variables or static/global variables which may hold on to the object reference across method calls. The content in this blog post is a combination of Product Group Guidance along with any edge cases that have been discovered in the field through support incidents.

To Dispose or not Dispose?! That is the question...

To make matters more confusing for SharePoint developers there are times when SPSite andSPWeb objects should not be disposed and are cleaned up by SharePoint and ASP.NET after page processing is completed. In addition, there are cases when developers indirectly call a property on a object that creates and holds an internal reference to a SPSite or SPWeb object (for example SPSite.ParentWeb property). Understanding the origin and the scope the object was created is paramount when determining whether or not to explicitly call dispose.

Why Dispose?

SPSite and SPWeb classes both implement the IDisposable interface. Microsoft .NET requires objects that implement the IDisposable interface to properly cleanup the unmanaged resources by explicitly calling the Dispose() method when you are finished using them. Internally, SPSite and SPWeb both hold references to an "internal class Microsoft.SharePoint.Library.SPRequest" which holds on to unmanaged COM resources. The consequence of not explicitly disposing unmanaged resources in a timely fashion can lead to not having enough memory for further allocations and quickly consumes memory. Under the hood, when reviewing dump files we see the that the managed objects used by SPSite and SPWeb are relatively small and it's the unmanaged resources that are most concerning and account for approximately 1MB to 2MB for each object instance! Omitting to explicitly call Dispose() means the .NET (non-deterministic) garbage collector gets out of sync with the finalizer and the unmanaged memory does not get reclaimed in a timely manner possibly blocking future memory allocations.

The unmanaged memory leaks can grow very quickly especially when traversing through frequently called areas like site navigation code and item event receivers. The lack of proper Dispose() hygiene can increase your risk of frequent IIS Application Domain recycles (see Steve Sheppard's blog Overlapped Recycling And SharePoint: Why SharePoint Requires It), Out Of Memory (OOM) exceptions, high memory consumption, and poor performing SharePoint production environments.

SPList.ParentWeb.Url & SPList.ParentWebUrl, are they really the same?

SPList.ParentWeb.Url & SPList.ParentWebUrl, are they really the same? or maybe not.
I was trying to get the Parent web url for a list that I have and noticed that they don’t really return the same Url.

Example:

You have a list Contacts on your root site http://myServer, and you got an instance of the SPList object for that list.

SPList.ParentWebUrl will return / where SPList.ParentWeb.Url will return http://myServer (which is what I really need)

MSDN says the following:

SPList.ParentWebUrl: Gets the URL of the parent Web site for the list.

SPList.ParentWeb.Url: Gets the absolute URL for the Web site.



So be careful of what you pick! Happy coding :-)