Memory Leak Issue When Streaming Data Over SSH

Hello Renci.SshNet Team,

I have encountered a memory leak issue when utilizing the library to stream data over SSH in a .NET application. The memory consumption of the application significantly increases over time and does not get released back, even after the SSH connection is closed and disposed of.

Environment:

Renci.SshNet Version: 2023 , 2020.1 ,2020.2
.NET Version: 7
Steps to Reproduce:

Establish an SSH connection and create a shell stream.
Write a command to the shell stream and continuously read the output.
Monitor the memory usage of the application.
Expected Behavior:
Memory should be released back once the data is read from the SSH stream and especially after the SSH client is disconnected and disposed of.

Actual Behavior:
Memory usage continuously increases as data is read from the SSH stream and is not released back after the SSH client is disposed of.

Code Sample:

csharp

static async Task<bool> CheckIfLinuxAsync(string[] parts)
{
    string sshIp = parts[0];
    if (!int.TryParse(parts[1], out int sshPort) || sshPort <= 0 || sshPort > 65535)
    {
        return false;
    }
    string username = parts[2];
    string password = parts[3];
    string sshKey = $"{sshIp}:{sshPort}:{username}:{password}";

    try
    {
        var client = _sshClients.GetOrAdd(sshKey, key =>
        {
            var sshClient = new SshClient(sshIp, sshPort, username, password);
            sshClient.ConnectionInfo.Timeout = TimeSpan.FromSeconds(5);
            sshClient.Connect();
            return sshClient;
        });

        if (!client.IsConnected)
        {
            client.Connect();
        }

        using (var command = client.CreateCommand("uname -a"))
        {
            await Task.Run(() => command.Execute()).ConfigureAwait(false);
            return command.Result.Contains("Linux", StringComparison.OrdinalIgnoreCase);
        }
    }
    catch
    {
        _sshClients.TryRemove(sshKey, out var clientToRemove);
        clientToRemove?.Dispose();
        return false;
    }

Profiling Details:

The application's memory usage increases significantly over time.
The memory does not get reclaimed even after disconnecting and disposing of the SSH client.

Attachments:

Additional Context:
This issue is critical for our use case where the application needs to run for extended periods, streaming data over SSH. The memory leak leads to increased resource usage and can eventually cause the application to run out of memory.

Any insights or workarounds would be greatly appreciated while this issue is being investigated and resolved.

Thank you for your time and assistance!

@hossein-mohseni

@hossein-mohseni, please provide a complete (but minimal) repo.

@drieseng

using System.Collections.Concurrent;
using System.Net.Sockets;
using System.Text;
using System.Threading.Tasks;
using Renci.SshNet;

namespace CoreApp
{
    class Program
    {
        private static readonly ConcurrentDictionary<string, SshClient> _sshClients = new ConcurrentDictionary<string, SshClient>();

        static async Task Main(string[] args)
        {
            try
            {
                using (TcpClient client = new TcpClient("127.0.0.1", 55555))
                using (NetworkStream stream = client.GetStream())
                {
                    byte[] buffer = new byte[4096];

                    while (true)
                    {
                        int bytesRead = await stream.ReadAsync(buffer, 0, buffer.Length).ConfigureAwait(false);
                        string receivedData = Encoding.UTF8.GetString(buffer, 0, bytesRead).Trim();

                        if (receivedData.Equals("exit", StringComparison.OrdinalIgnoreCase))
                        {
                            DisconnectAndDisposeAllClients();
                            break;
                        }

                        string[] parts = receivedData.Split(':');

                        if (parts.Length != 4)
                        {
                            continue;
                        }

                        bool isLinux = await CheckIfLinuxAsync(parts).ConfigureAwait(false);

                        byte[] responseData = Encoding.UTF8.GetBytes($"{receivedData}#{isLinux}");

                        await stream.WriteAsync(responseData, 0, responseData.Length).ConfigureAwait(false);
                    }
                }
            }
            catch
            {
            }
        }

        static async Task<bool> CheckIfLinuxAsync(string[] parts)
        {
            string sshIp = parts[0];
            if (!int.TryParse(parts[1], out int sshPort) || sshPort <= 0 || sshPort > 65535)
            {
                return false;
            }
            string username = parts[2];
            string password = parts[3];
            string sshKey = $"{sshIp}:{sshPort}:{username}:{password}";

            try
            {
                var client = _sshClients.GetOrAdd(sshKey, key =>
                {
                    var sshClient = new SshClient(sshIp, sshPort, username, password);
                    sshClient.ConnectionInfo.Timeout = TimeSpan.FromSeconds(5);
                    sshClient.Connect();
                    return sshClient;
                });

                if (!client.IsConnected)
                {
                    client.Connect();
                }

                using (var command = client.CreateCommand("uname -a"))
                {
                    await Task.Run(() => command.Execute()).ConfigureAwait(false);
                    return command.Result.Contains("Linux", StringComparison.OrdinalIgnoreCase);
                }
            }
            catch
            {
                _sshClients.TryRemove(sshKey, out var clientToRemove);
                clientToRemove?.Dispose();
                return false;
            }
        }

        static void DisconnectAndDisposeAllClients()
        {
            foreach (var kvp in _sshClients)
            {
                try
                {
                    kvp.Value.Disconnect();
                }
                catch
                {
                }
                finally
                {
                    kvp.Value.Dispose();
                }
            }
            _sshClients.Clear();
        }
    }
}

@drieseng

i make it to receive the server info from a local socket.

this is a alpha version code just to test the performance and resource usage of the ssh .net in my code.

any news?

@hossein-mohseni

@hossein-mohseni i think @drieseng was asking for an entire git repository, as opposed to copy/pasted code.

having a standalone codebase that consistently reproduces problematic behavior (for any triage request) is a key before spending much time triaging the issue - even if it's your own code/issue. an easy way to share these standalone codebases is via repos. anyways, good luck if you haven't found the issue yet... if you have, perhaps consider closing this issue(?)

There will be a new version coming out soon with a lot of the core internals being rewritten. I'd recommend you give it a try when it comes out and see if the issue is still present.

Ok I will test the new version and I hope the problem be fixed 🌹

Thanks

Looks like the problem still exists in SSH.NET 2024. If we keep connection alive and continue to execute ssh commands using either RunCommand or CreateCommand then the amount of handles continues to grow until finally the application will throw OutOfMemory exception. Currently the only way to prevent it from happening is to periodically dispose and create a new ssh connection.

@SzamanSZ

@SzamanSZ what kind of handles? More information would be appreciated/required here.

Looks like the problem still exists in SSH.NET 2024. If we keep connection alive and continue to execute ssh commands using either RunCommand or CreateCommand then the amount of handles continues to grow until finally the application will throw OutOfMemory exception. Currently the only way to prevent it from happening is to periodically dispose and create a new ssh connection.

Is there anyway you can repro locally on your dev machine?

@Rob-Hague

@Rob-Hague Task Manager -> Details tab -> Select columns -> Add "Handles" to see the number of handles growing.
@jscarle Try a very simple piece of code like the one below and you will see the numer of handles in Task Manager keeps growing. If you use a large enough value for i, eventually you will get OutOfMemory exception. This could take some time (in my real world case it reached 1.6 million handles) but if you have a program having 10-20 connections to different servers running commands every second or so, the application can crash within couple of hours (in my real world case it was 8-9h). Only once client is disposed, those handles are freed. So some objects must be created during the command execution and the references to them are not being freed properly so the GC cannot free them.

            SshClient sshClient = new SshClient("localhost", "user", "password");
            sshClient.Connect();
            int i = 0;
            while (i < 100000)
            {
                i++;
                var sshCommand = sshClient.RunCommand("dir");
                string result = sshCommand.Result;
                Console.WriteLine(i);
            }
            sshClient.Disconnect();
            sshClient.Dispose();

SshCommand is disposable, and you're not disposing it.

Does this still produce the same issue?

            SshClient sshClient = new SshClient("localhost", "user", "password");
            sshClient.Connect();
            int i = 0;
            while (i < 100000)
            {
                i++;
                using var sshCommand = sshClient.RunCommand("dir");
                string result = sshCommand.Result;
                Console.WriteLine(i);
            }
            sshClient.Disconnect();
            sshClient.Dispose();

@jscarle

@jscarle Thank you, this fix works, however... The Dispose() method and finalizer of SshCommand (currently I did not see any finalizer in the code) should be refactored in such way that the finalizer should call the Dispose method if a user forgets to call Dispose().

I don't think that's true. A finalizer is only used to release unmanaged resources, of which there are none in SshCommand (neither in 2024.0.0 nor on current develop branch which looks a lot different). See https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-dispose:

A finalizer is only required if you directly reference unmanaged resources.

If you think there is an improvement then feel free to raise a PR.

If all resources were managed, there would be no need to ever call Dispose() as in the beautiful world of .NET we shouldn't need to call it. We can call to free resources faster but it should not be required. All managed resources should eventually be freed by GC itself when they are no longer in use. But that does not seem to be the case here. In the Dispose method of SshCommand, there are other things happening such as removing the event handlers. Perhaps those are the ones that cause the handle leak without calling the Dipose or using statement. The most excellent answer on implementing IDisposable is here: https://stackoverflow.com/questions/538060/proper-use-of-the-idisposable-interface

So yes, I think that would definitely be an improvement :)

Yes, it could well be the event handlers on Session causing the SshCommand object to stay alive, hence (in version 2024.0.0) the CommandAsyncResult hence the WaitHandle on CommandAsyncResult. On the develop branch, there are no (explicit) wait handles but the SshCommand would still be kept alive without Dispose.

Nothing in the SO link appears to contradict my understanding in this area, but I will happily review your PR to clarify and make improvements here.

You are correct, however even there they recommend calling Dispose(false) from the finalizer. Perhaps the finalizer should call Dispose(false) and if the disposing==false it should remove the event handlers (I did not test that if that would solve the problem with leaking handles I mentioned earlier). Other managed objects should be eventually handled by GC. The thing is, I completely agree with you, as a rule of thumb we should always call Dispose on objects that implement IDisposable. But if we don't, for any reason, then the finalizer will be eventually called by the GC and it should still be able to free resources.

The problem is that we can't access the Session object which holds the events, or generally any managed object from the finalizer of SshCommand because finalizers run non-deterministically and the managed objects are not guaranteed to exist at that point.

It doesn't seem worth solving to me. If you have an IDisposable: Dispose it

if the disposing==false it should release unmanaged resource (like IntPtr).

@Rob-Hague

Unless you're using this code is an old version of .NET, the discussion regarding finalizers is less and less relevant by the day. Although that used to be a consideration, .NET 5 (including .NET Core) and later versions don't call finalizers as part of application termination. Also, if you have a Finalize method, don’t try to clean up managed objects from it.

.NET goes to great lengths to manage resources for you. Event handlers are managed resources. Finalizers are no substitution for best practices while writing application code (such as calling Dispose). So I have to agree with @Rob-Hague on this, unless we're missing somewhere within the library code that's not calling dispose where it should, then there's likely no improvement to be made here.

@jscarle

@jscarle Yes, event handlers are managed resources. However, if they stay assigned, a reference to them exists, and they will never be freed automatically.

I do not oppose the best practices at all. But if there is any way for improvement, it could be considered. That's all.

The fact that the finalizers aren't called as part of application termination has nothing to do with the current discussion (and the OS will free the resources anyway). The other link simply re-states everything we said here - that finalizers should call Dispose(false).

My simple point is: when we are writing the code, we don't know whether the specific class implements IDisposable or not - do you check every new class for the existence of Dispose() method? And even in the SSH.NET tests (e.g. https://github.com/sshnet/SSH.NET/blob/develop/test/Renci.SshNet.Tests/Classes/SshCommandTest.cs) nobody is disposing SshCommand or making using statement around it. They only wrap using around SshClient (I know, not a biggie when we execute just one command but... hey, didn't you just say it's the bad practice not to call Dispose?). With sparse documentation, how would I ever know that I should dispose the SshCommand object without ever reaching out to you guys (btw. I am eternally thankful for your quick answers).

PR to improve the UT to dispose the SshCommand is warmly welcome

@SzamanSZ

@SzamanSZ

My simple point is: when we are writing the code, we don't know whether the specific class implements IDisposable or not - do you check every new class for the existence of Dispose() method?

Yes, I do.

With sparse documentation, how would I ever know that I should dispose the SshCommand object without ever reaching out to you guys

Not sure where it's spare. It's documented here that it's disposable: https://sshnet.github.io/SSH.NET/api/Renci.SshNet.SshCommand.html

It even mentions non-existing finalizer :) at the bottom of the page.
Homepage (https://sshnet.github.io/SSH.NET/) claims that "Currently (4/18/2020), the documentation is very sparse" and sends everyone to unit tests. Without you posting that link, I'd probably never end up seeing it (thanks again).

@WojciechNagorski

@WojciechNagorski At the homepage of the repository, in the about section, in the gear , it would be useful to check this:

Release SshCommand's session subscriptions and channel on completion (s…

I've opened #1846 for the "long-lived SshClient, RunCommand/CreateCommand results not disposed" scenario from the comments above. It doesn't touch the ShellStream scenario of the original report.

I agree that disposing the command is the right thing to do and that a finalizer can't help here. The session's event handlers keep the command reachable, so it never becomes eligible for finalization. What the PR changes is that a completed command no longer needs the session to reference it:

the channel is created and the session events are subscribed in ExecuteAsync rather than in the constructor;
the session subscriptions are removed when the execution completes, on any path;
the channel is disposed once the execution has completed and no thread is still waiting in SendExecRequest. A small use count keeps the Don't dispose channel when completing SshCommand #1596 race (SSH_MSG_CHANNEL_CLOSE processed before SendExecRequest finishes waiting) fixed.

After that, an undisposed command and its channel can be garbage-collected. There are unit tests for this, including a WeakReference/GC test. Details are in the PR description.

Disclosure, per CONTRIBUTING.md: the analysis and the change were written with Claude (Claude Code) under my direction.

Navigation Menu

Repository navigation

Memory Leak Issue When Streaming Data Over SSH #1204

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Memory Leak Issue When Streaming Data Over SSH #1204

Description

Activity

drieseng commented on Oct 13, 2023

hossein-mohseni commented on Oct 13, 2023

hossein-mohseni commented on Oct 25, 2023

isandburn commented on Feb 19, 2024

jscarle commented on Feb 19, 2024

hossein-mohseni commented on Feb 23, 2024

SzamanSZ commented on Jun 24, 2024

Rob-Hague commented on Jun 24, 2024

jscarle commented on Jun 24, 2024

SzamanSZ commented on Jun 24, 2024

jscarle commented on Jun 24, 2024

SzamanSZ commented on Jun 25, 2024

Rob-Hague commented on Jun 25, 2024

SzamanSZ commented on Jun 25, 2024

Rob-Hague commented on Jun 25, 2024

SzamanSZ commented on Jun 25, 2024

Rob-Hague commented on Jun 25, 2024

scott-xu commented on Jun 25, 2024

jscarle commented on Jun 25, 2024

SzamanSZ commented on Jun 25, 2024

scott-xu commented on Jun 25, 2024

jscarle commented on Jun 25, 2024

SzamanSZ commented on Jun 25, 2024

jscarle commented on Jun 25, 2024

harsh-official commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions