Memory Leak in CMS prior to 9.0.2

This bug appears only in load-balanced / remote events setups for CMS versions between 7.5 and 9.0.2 (released September 14th 2015, in which it was fixed). It’s reported as bug CMS-1405. This memory leak is relatively slow. Because of the way that ASP.NET handles cache, the application’s memory allocation will remain constant while the cache portion of it will continuously decrease ending up in an application with no cache at all.

Here’s a quick patch that fixes the issue for sites running this code:

Recognizing it

After leaving your application running for some time, take a full user dump of the application (using through Task Manager/Right Click w3wp.exe/Create Dump File, ProcDump -ma and the like).
Open it up in WinDBG, and load the SOS extension. Being lazy, I first let the .loadby sos clr attempt loading and fail. It fails because the dump I analyze was taken off an Azure server, which has the system loaded on the D:-drive. Copy the path, sans the first character which I change to a C, and the SOS extension loads properly.

Then I call !dumpheap -stat . After crunching for a while, it will write out a table with all the different types of objects in your application, sorted by the biggest space-takers in the bottom:

In this dump, I found more than 3 million instances of each of these types. Together, they take up 102+153 MB of memory. You would typically not expect any more instances than the number of remote events that could be emitted within a 5 second time span. That number is well below 3 million! That’s 255 MB wasted!

Downloads

Source package that you may open and build yourself.
Binary package with a DLL that’s simply installed into the /bin/-folder.

 

2 thoughts on “Memory Leak in CMS prior to 9.0.2”

    1. Sorry, I left out a using statement:
      using EPiEvents = EPiServer.Events;
      Also, I updated the code sample above.

Leave a Reply

Your email address will not be published. Required fields are marked *