zeromq / netmq

A 100% native C# implementation of ZeroMQ for .NET
Other
2.94k stars 742 forks source link

Memory leak on repeated reconnection attempts #1037

Open Drutol opened 1 year ago

Drutol commented 1 year ago

Environment

NetMQ Version:    4.0.1.10
Operating System:  Ubuntu 20.04.5 LTS/Windows 10 19045
.NET Version:  net6.0   

Expected behaviour

No memory leak on repeated connect/disconnect calls.

Actual behaviour

Library is leaking memory when you try to repeatedly connect/disconnect in attempt to reconnect to remote host after some form of network interruption leading to a disconnection. Not sure if there's any better approach to reconnecting.

Steps to reproduce the behaviour

Consider given code:

  var pub = new PublisherSocket();
  var port = pub.BindRandomPort("tcp://127.0.0.1");
  for (int i = 0; i < 1000; i++)
  {
      var sub = new SubscriberSocket();
      sub.Connect("tcp://127.0.0.1:" + port);
      sub.Subscribe("A");
      sub.Disconnect("tcp://127.0.0.1:" + port);
      sub.Dispose();
      Thread.Sleep(50);
  }

It will repeatedly connect and disconnect to the single pub socket. Unfortunatelly Close/Disconnect/Dispose methods won't fully cleanup used resources as visible on Visual Studio profiler: image

There is ever increasing number of Pipe instances. image

I've been trying to pinpoint the issue in cloned repository but I'm unable to find it. What I've noticed is that when counting created Pipe instances only other 2nd pair will be garbage collected eg: (not entirely sure if it's a good indicator)

  private Pipe(
      ZObject parent, YPipe<Msg> inboundPipe, YPipe<Msg> outboundPipe,
      int inHighWatermark, int outHighWatermark, int predefinedLowWatermark)
      : base(parent)
  {
...
      _id = Interlocked.Increment(ref IdCounter);
      Console.WriteLine($"Created: {_id}");
  }

    ~Pipe()
  {
      Console.WriteLine($"Finalized: {_id}");
  }
Created: 1 (Pipe constructor)
Created: 2
Created: 3
Created: 4
Created: 5
Created: 6
Created: 7
Created: 8
Created: 9
Created: 10

Finalized: 10 (Pipe finalizer)
Finalized: 9
Finalized: 6
Finalized: 5
Finalized: 2
Finalized: 1

This suggests that the pipes of pub sockets are left around.

The memory has been leaking over the span of several days/weeks including the case where the pub socket was on remote system.

Thanks for help!

8 commented 1 year ago

Thanks for posting the defect. I think I have stumbled over the same bug. image If I have new findings I will update my comment.