IndividualAssemblyLoadContext XmlSerializers.dll memory leak-CodePudding

The

I created two memory dumps. One with high memory and one after restart and it's clearly visible that the reason is the app trying to load XmlSerialization.dll multiple times.

Now we have multiple other APIs that are using almost identical code when it comes to serialization and I'm not exactly sure why the problem occurs only in this one. Potentially because maybe this one has a much higher traffic when using the APIs.

I've read some articles about XmlSerializer class having memory issues but those were listed for some of the constructors we are not using. The only instance of using XmlSerializer directly in code was using an XmlSerializer(Type) constructor.

private static async Task<T> ParseResponseContentAsync<T>(HttpResponseMessage response, Accept accept) { try { using (Stream contentStream = await response.Content.ReadAsStreamAsync()) { using (StreamReader reader = new StreamReader(contentStream, Encoding.UTF8)) { switch (accept) { case Accept.Xml: XmlSerializer serializer = new XmlSerializer(typeof(T)); return (T)serializer.Deserialize(reader); case Accept.Json: string stringContent = await reader.ReadToEndAsync(); return JsonConvert.DeserializeObject<T>(stringContent); default: throw new CustomHttpResponseException(HttpStatusCode.NotImplemented, $"Unsupported Accept type '{accept}'"); } } } } catch (Exception ex) { throw new InvalidOperationException($"Response content could not be deserialized as {accept} to {typeof(T)}", ex); } }

But I'm pretty sure this method is not used in this API anyway .

So another potential problematic place could be somewhere in the Controller serialization of responses.

Startup.cs registration:

services .AddControllers(options => { options.OutputFormatters.Add(new XmlSerializerOutputFormatter( new XmlWriterSettings { OmitXmlDeclaration = false })); options.Filters.Add<CustomHttpResponseExceptionFilter>(); }) .AddNewtonsoftJson(options => options.SerializerSettings.Converters.Add( new StringEnumConverter(typeof(CamelCaseNamingStrategy)))) .AddXmlSerializerFormatters();

Example of an endpoint:

[Produces(MimeType.ApplicationXml, MimeType.TextXml, MimeType.ApplicationJson, MimeType.TextJson)] [ProducesResponseType(StatusCodes.Status200OK)] [ProducesResponseType(StatusCodes.Status404NotFound)] [ProducesResponseType(StatusCodes.Status401Unauthorized)] [HttpGet("EndpointName")] [Authorize] public async Task<ActionResult<ResponseDto>> Get([FromModel] InputModel inputModel) { //some code return responseDto; }

Dto returned from the API:

[XmlRoot(ElementName = "SomeName")] public class ResponseDto { [XmlElement(ElementName = "Result")] public Result Result { get; set; } [XmlAttribute(AttributeName = "Status")] public string Status { get; set; } [XmlAttribute(AttributeName = "DoneSoFar")] public int DoneSoFar { get; set; } [XmlAttribute(AttributeName = "OfTotal")] public int OfTotal { get; set; } }

Now I haven't been able to find any documented cases of .AddXmlSerialization causing these kinds of issues and I'm not sure what the solution or a workaround should be. Any help would be greatly appreciated.

EDIT: I've run some additional tests as @dbc suggested.

Now it seems that we are not even hitting this line new XmlSerializer(typeof(T) in our scenarios since nothing was logged after logger code was added. We do however use default xml serialization for some of our API endpoints. Now one thing I noticed that might be causing this behavior is that the paths in memory dumps logs don't match the files that actually exist in the root folder.

The paths which are visible in memory dumps are *.Progress.Lib.XmlSerializers.dll or *.Domain.Lib.XmlSerializers.dll

Now I wonder if this isn't the issue documented here -

CodePudding user response：

This might not be feasible, but could you offload the XML generation onto Azure API Management?
https://learn.microsoft.com/en-us/azure/api-management/api-management-transformation-policies#ConvertJSONtoXML

CodePudding user response：

The assemblies that the new XmlSerializer(typeof(T)) constructor are trying to load are Microsoft XML Serializer Generator assemblies a.k.a Sgen.exe assemblies that might have or might not been created at the time the app was built.

But what are Sgen assemblies? In brief, XmlSerializer works by generating code to serialize and deserialize the type passed into the constructor, then compiling that generated code into a DLL and loading it into the application domain to do the actual serialization. This run-time DLL generation can be time-consuming, but as long as you use the XmlSerializer(Type) or XmlSerializer(Type, String) constructors it will only be done once per type T, with the resulting assembly being cached internally in a static dictionary by XmlSerializer.

As you might imagine this can cause the first call to new XmlSerializer(typeof(T)) to be slow, so (in .NET 2 I believe, this is all very old code) Microsoft introduced a tool to generate those run-time serialization DLLs at application build time: SGen.exe. This tool doesn't work for all types (e.g. generics) and was, if I recall correctly, finicky to use, but when it did work it did speed up serializer construction. Once loaded successfully the Sgen assembly is cached in the same cache used for generated assemblies.

And it seems like you have stumbled across a bug in .NET Core 3.1, 5, and 6 related to this:

The base class method OutputFormatter.CanWriteResult(OutputFormatterCanWriteContext context) of XmlSerializerOutputFormatter tests whether a type can be serialized by calling XmlSerializerOutputFormatter.CanWriteType(Type type). This in turn tests to see whether a type is serializable by XmlSerializer by attempting to construct a serializer for the type and returning false if construction failed because any exception was thrown. The serializer is cached if construction was successful, but nothing is cached if construction failed.

the new XmlSerializer(Type) constructor tries to load an Sgen assembly unless an assembly has already been cached for the type by a previous successful call to the constructor.

But if a type is not serializable by XmlSerializer, the constructor will throw an exception and nothing will be cached. Thus successive attempts to construct a serializer for the same non-serializable type will result in multiple calls to load Sgen assemblies.

As you yourself found, .NET Core itself permanently leaks a small amount of IndividualAssemblyLoadContext memory every time assembly load fails: Failed Assembly.Load and Assembly.LoadFile leaks memory #58093.

Putting all this together, enabling XML serialization when some of your DTOs are not serializable (because e.g. they don't have parameterless constructors) can result in ever-growing IndividualAssemblyLoadContext memory use.

So, what are your options for a workaround?

Firstly, issue #58093 was apparently fixed in .NET 7 with pull #68502 so if you upgrade to this version the problem may resolve itself.

Secondly, you could subclass XmlSerializerOutputFormatter to cache returned XmlSerializer instances even when null. This will prevent multiple attempts to create serializers for non-seializable types.

First, subclass XmlSerializerOutputFormatter and override XmlSerializerOutputFormatter.CreateSerializer(Type) as follows:

public class CachedXmlSerializerOutputFormatter : XmlSerializerOutputFormatter { // Cache and reuse the serializers returned by base.CreateSerializer(t). When null is returned for a non-serializable type, // a null serializer will be cached and returned. static readonly ConcurrentDictionary<Type, XmlSerializer> Serializers = new ConcurrentDictionary<Type, XmlSerializer>(); public CachedXmlSerializerOutputFormatter() : base() { } public CachedXmlSerializerOutputFormatter(ILoggerFactory loggerFactory) : base(loggerFactory) { } public CachedXmlSerializerOutputFormatter(XmlWriterSettings writerSettings) : base(writerSettings) { } public CachedXmlSerializerOutputFormatter(XmlWriterSettings writerSettings, ILoggerFactory loggerFactory) : base(writerSettings, loggerFactory) { } protected override XmlSerializer CreateSerializer(Type type) { return Serializers.GetOrAdd(type, (t) => base.CreateSerializer(t)); } }

Then replace use of XmlSerializerOutputFormatter with your subclassed version as follows:

services .AddControllers(options => { options.OutputFormatters.Add(new CachedXmlSerializerOutputFormatter ( new XmlWriterSettings { OmitXmlDeclaration = false })); options.Filters.Add<CustomHttpResponseExceptionFilter>(); }) .AddNewtonsoftJson(options => options.SerializerSettings.Converters.Add( new StringEnumConverter(typeof(CamelCaseNamingStrategy)))) .AddXmlSerializerFormatters();

This should in theory eliminate the repeated failing calls to load Sgen assemblies.

Demo fiddles:

Demo fiddle showing that that multiple calls to XmlSerializerOutputFormatter.CanWriteType() for a non-serializable DTO result in multiple assembly load failures here: demo #1.

Demo fiddle showing that CachedXmlSerializerOutputFormatter fixes this problem here: demo #2.

Demo that multiple calls to XmlSerializerOutputFormatter.CanWriteType() for a serializable DTO do not result in multiple assembly load failures, and hence don't cause growing IndividualAssemblyLoadContext memory use, here: demo #3.