3

I'm troubleshooting a memory leak in a windows service that is used as an integration service.

Per "doIntegration()" call I can see that the memory usage gets higher than before the call, and that it rises about 0,5 MB per call.

I have tried using PerfView to locate where the memory leak(s) might be.

Troubleshooting method:

1) Take heap snapshot before the first doIntegraion call

2) Take heap snapshot after the doIntegration call

3) Do step 2 multiple times

4) Check what Method/Group gets higher per call

5) Use the diff on the separate snapshots to locate where the memory leak is

I can see that LIB mscorlib!RuntypeType is the method/group that gets higher each time. When I try to check what refers to it I get

  • Pinned handles
    • .NET Root
      • ROOT

And I am not able to expand the tree more.

When I choose the view, RefTree I get to see some more things.

  • ROOT 100%
    • .NET ROOT 100%
      • Pinned Handles 70.6%
        • LIB mscorlib!RuntimeType 46%
        • LIB mscorlib!reflection.... 13.4% ...
      • Static vars 30.7%
        • ns.ConfigurationSettings 59.5%
        • ns.Leaks.ConfigurationSettings -33.3%

I have done a diff on several snapshots, and the only method/group that increments is the Pinned handles and they only refer to mscorlib types.

Have anyone else had this kind of problem?

I think the problem might be in serialization from Model to XML using XMLSerializer, but I'm not really sure.

Does anyone know another way to try and find the memory leak(s)?

Thanks :)

Alex
  • 487
  • 1
  • 6
  • 19
  • Look at stack traces where these objects are created, may be it will prompt you what these objects are. – Ed Pavlov Oct 15 '15 at 12:33
  • Thanks! I have tried to trace it and as I assumed it is due to the serializer. The serializer is opened with a constrctor that creates a temp assembly, and apparently that assembly is outside of GCs juridiction. So for each time the dointegration is called, several temp asemblies are created. – Alex Oct 16 '15 at 07:39

1 Answers1

4

The answer comes pretty late. But I were right in my assumption that it was the serializer that incremented the memory usage per "doWork".

XmlSerializer has some "nasty" constructors that will actually create a temp assembly per init and they won't be collected by GC.

I cached the different XmlSerializers that used one of the nasty constructors so that the temp assembly only gets created once.

Now there are no memory leaks left.

Alex
  • 487
  • 1
  • 6
  • 19