0

This is a follow-on question to this one: XmlSerializer extraTypes memory leak

I have used the technique of having a single static call using the extratypes overload like this:

static readonly XmlSerializer xmlSerializer = new XmlSerializer(typeof(MyDeviceType[]), MyDeviceTypes);

where MyDeviceTypes looks like this:

static readonly Type[] MyDeviceTypes = { typeof(DeviceType1), typeof(DeviceType2) };

The problem I am seeing now is that I am getting a memory jump every time I call Serialize:

Logger.LogError("SaveDevices: Before Serialize call - " + GetMemoryUsage());
xmlSerializer.Serialize(xwriter, devices); 
Logger.LogError("SaveDevices: After Serialize call - " + GetMemoryUsage());

So my log looks like this:

9/28/2016 5:14:32 PM SaveDevices: Before Serialize call - 344,182,784
9/28/2016 5:14:36 PM SaveDevices: After Serialize call - 359,600,128

and I see the same increases every time Serialize is called with memory never being released, eventually causing an Out of Memory error.

I tried setting the XmlSerialization.Compilation switch in app.config and I don't get any source code to peek at, but I do see a Microsoft.GeneratedCode.dll and Microsoft.GeneratedCode.pdb file. When I watch my application run, it appears that this file is regenerated every time Serialize is called.

How can I modify this behavior so it doesn't keep consuming memory on each Serialize call and regenerate the code each time?

Update: Replacing the my complex data types with simple test data types stops the strange behavior from occurring (i.e. no memory leak and no regeneration of the Microsoft.GeneratedCode). What in my complex data types could cause the calls to Serialize to decide it needs to regenerate each time it is called?

Community
  • 1
  • 1
Dale K
  • 91
  • 1
  • 5
  • Are you disposing `xwriter` properly? And what is its type? – kiziu Sep 29 '16 at 13:18
  • Have you seen [this answer](http://stackoverflow.com/a/23897411/1997232)? – Sinatr Sep 29 '16 at 13:22
  • @Sinatr, OP mentioned that `xmlSerializer` is cached in `static readonly` field. – kiziu Sep 29 '16 at 13:23
  • xwriter is type XmlWriter. I don't believe it is the issue as the memory bump happens all within the scope of when xwriter is used. I also tried putting a using statement with xwriter around the whole usage of its lifetime and it had no effect. – Dale K Sep 29 '16 at 13:31
  • I cannot reproduce your problem in a simple test console app - see [here](http://pastebin.com/5KEPPTgW) for the code. When I run the test app, memory use quickly stabilizes at 524640 bytes. Can you [edit] your question to provide a [mcve]? – dbc Oct 03 '16 at 15:29
  • 1
    This one is getting interesting. I tried to recreate it with the simple app and couldn't get the behavior to occur. I then tried replacing my types with dummy data types and the strange behavior still didn't occur, so it appears that the issue is somehow related to the types we have defined. Any ideas what could be defined in my types that would cause the Serialize call to regenerate code every time it is called? – Dale K Oct 05 '16 at 12:52

1 Answers1

0

We were able to resolve this issue by performing the work requiring XmlSeralizer in another application domain, then passing the necessary results back to the calling domain as suggested in the answer commentary here: XmlSerializer extraTypes memory leak. The AppDomainToolkit from here: https://github.com/jduv/AppDomainToolkit made life much simpler.

Community
  • 1
  • 1
Dale K
  • 91
  • 1
  • 5