Are there still known memory leaks with XML serialization in .NET 4?

Question

Our application is leaking memory. We did not yet run a memory profiler on it. I found plenty of blog posts and other about that leak in CLR 2 (.NET 2, .NET 3.5). So I was wondering if anyone knows if this is still an issue in CLR 4 (.NET 4)..

(I found this on SO: Are there still known memory leaks with XMLSerialization in .Net 3.5?)

Are you using `XmlAttributeOverrides` ? If you are: that needs to be treated carefully... not so much a *leak*, as: if used ***incorrectly*** it will haemorrhage; if used correctly: it won't — Marc Gravell, Aug 28 '13 at 11:30
I'd be looking for self inflicted ones before I pointed the finger at Redmond, and I'm not one of their biggest fans.... — Tony Hopkinson, Aug 28 '13 at 11:38
I didn't mean to point any fingers :) I just know about the issue in CLR 2 and was wondering if anyone experienced the issue in CLR 4.. @Marc: not using that.. When we will find the answer ourselves, I will repot back here :) — TweeZz, Aug 29 '13 at 11:38
The "issue" is not general, like pretending the whole thing is completely buggy and noone at Microsoft doesn't care. It's only in specific cases that the architecture of Xml Serialization has drawbacks that need to be taken in consideration. — Simon Mourier, Sep 08 '13 at 16:05
This issue is by design, it will never change. It is not a bug. Think of an XmlSerializer as an expensive resource that is best put into a static field or some other cache. — usr, Sep 08 '13 at 16:29
They could just maybe push the caching mechanism they are using to cache the instances created with the 'simple' constructor a bit further.. To for example extend it not only based on object type, but also based on the XmlRootAttribute ElementName.. I think that would be enough for plenty of people.. They could take it even further by also including the specified namespace in the cache key. — TweeZz, Sep 08 '13 at 17:02

score 0 · Accepted Answer · edited May 23 '17 at 12:31

0

I can confirm that the XmlSerializer is still behaving the same as in older .NET versions. A way around this leak is to implement a small caching mechanism as described here:

XmlSerializer Performance Issue when Specifying XmlRootAttribute

edited May 23 '17 at 12:31

Community

1
1

answered Sep 08 '13 at 16:01

TweeZz

4,779
5
39
53

score 0 · Answer 2 · edited May 23 '17 at 11:52

The best answer I found on SO was this: https://stackoverflow.com/a/36123026/2941313

If you follow the link to the msdn page about XmlSerializer, you can still see this comment:

To increase performance, the XML serialization infrastructure dynamically generates assemblies to serialize and deserialize specified types. The infrastructure finds and reuses those assemblies. This behavior occurs only when using the following constructors:

XmlSerializer.XmlSerializer(Type)

XmlSerializer.XmlSerializer(Type, String)

If you use any of the other constructors, multiple versions of the same assembly are generated and never unloaded, which results in a memory leak and poor performance. The easiest solution is to use one of the previously mentioned two constructors. Otherwise, you must cache the assemblies in a Hashtable, as shown in the following example.

And there are examples of proper hasing... So I guess, the answer is yes, but you can work around those memory issues.

Are there still known memory leaks with XML serialization in .NET 4?

2 Answers2