[GH-ISSUE #1136] Memory leak with Windows build #910

Open
opened 2026-05-05 07:16:12 -06:00 by gitea-mirror · 7 comments
Owner

Originally created by @DavidInvenio on GitHub (Apr 19, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1136

The barrier.exe process memory usage increases forever, or at least until the system chokes and I kill off all the barrier processes. I am using barrier on a Win7 Ultimate 64bit as the server which has the keyboard/mouse I use to control 2 other Win7 machines and 1 Linux(Raspberry Pi4). The problem only exists on the server, but it is barrier.exe and not barriers.exe that has the problem. I can open task manager and watch the memory usage climb indefinitely. I am using the latest version downloaded here and all my machines are updated/patched up to date.

To reproduce, just run it and open task manager. I don't know if the problem exists on Windows 10 because I don't use it.

Originally created by @DavidInvenio on GitHub (Apr 19, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1136 The barrier.exe process memory usage increases forever, or at least until the system chokes and I kill off all the barrier processes. I am using barrier on a Win7 Ultimate 64bit as the server which has the keyboard/mouse I use to control 2 other Win7 machines and 1 Linux(Raspberry Pi4). The problem only exists on the server, but it is barrier.exe and not barriers.exe that has the problem. I can open task manager and watch the memory usage climb indefinitely. I am using the latest version downloaded here and all my machines are updated/patched up to date. To reproduce, just run it and open task manager. I don't know if the problem exists on Windows 10 because I don't use it.
Author
Owner

@DavidInvenio commented on GitHub (Apr 30, 2021):

Woohoo I finally figured out the problem! Well in my case anyway, not sure if it's the same for everyone. But what I found is that if I configure my "server" (meaning the machine with the keyboard/mouse physically attached) for a computer that is either reconfigured or not running Barrier, then the server eats ram indefinitely until it becomes unusable, presumably swapping like mad but is unresponsive long before then. These are both Windows7 and Linux machines but the server is always Win7. I use static IPs and local etc/hosts files, so no external DNS issues. And this is all on a single internal subnet with no firewalls enabled on any machine, and with Win7 gutted down to the absolute minimum. And the minute I remove the unreachable computer from the Barrier config and restart it, everything works perfectly.

So I certainly wouldn't consider this a major bug, but there's definitely a more elegant way of dealing with a machine being unreachable! The machine might be ping-able and just not running Barrier, so checking for a ping won't resolve it.

PS: I might be able to dig through the source and offer a patch to fix this, however despite 36 years coding I doubt I'm anywhere near as good as the team members and I've been focused on c# for quite a few years which I doubt is the lang being used. But if someone asks me to step up I would try my best.

<!-- gh-comment-id:830410728 --> @DavidInvenio commented on GitHub (Apr 30, 2021): Woohoo I finally figured out the problem! Well in my case anyway, not sure if it's the same for everyone. But what I found is that if I configure my "server" (meaning the machine with the keyboard/mouse physically attached) for a computer that is either reconfigured or not running Barrier, then the server eats ram indefinitely until it becomes unusable, presumably swapping like mad but is unresponsive long before then. These are both Windows7 and Linux machines but the server is always Win7. I use static IPs and local etc/hosts files, so no external DNS issues. And this is all on a single internal subnet with no firewalls enabled on any machine, and with Win7 gutted down to the absolute minimum. And the minute I remove the unreachable computer from the Barrier config and restart it, everything works perfectly. So I certainly wouldn't consider this a major bug, but there's definitely a more elegant way of dealing with a machine being unreachable! The machine might be ping-able and just not running Barrier, so checking for a ping won't resolve it. PS: I might be able to dig through the source and offer a patch to fix this, however despite 36 years coding I doubt I'm anywhere near as good as the team members and I've been focused on c# for quite a few years which I doubt is the lang being used. But if someone asks me to step up I would try my best.
Author
Owner

@DavidInvenio commented on GitHub (Apr 30, 2021):

I also want to add how sincerely THANKful I am for this wonderful utility and how much I APPRECIATE all the effort and expertise of everyone on the team. This is one of the best open source applications I've ever used and one of the most useful as well. So my sincere THANKS to everyone.

<!-- gh-comment-id:830414199 --> @DavidInvenio commented on GitHub (Apr 30, 2021): I also want to add how sincerely THANKful I am for this wonderful utility and how much I APPRECIATE all the effort and expertise of everyone on the team. This is one of the best open source applications I've ever used and one of the most useful as well. So my sincere THANKS to everyone.
Author
Owner

@PythonTryHard commented on GitHub (Oct 5, 2021):

Reproducible on Windows 10 2004 (build 19041.1237) running Barrier 2.3.2.

Steps to reproduce:

  1. Set up Barrier as server make sure it starts barrierd.exe on startup. Don't connect to anything to the server.
  2. For physical 8GB of RAM, leave it for 5 days (yes, I mean it). Adjust the amount of RAM down for less waiting.
  3. Inspect RAM usage with Task Manager and SysInternal RAMMap.

Result:
I didn't capture any screenshots because I was trying to save my system but from what I saw:

  • With 8 tabs of Firefox, Task Manager reported 7.6/7.8GB usage while a fresh boot would only consume to somewhere around 4.1/7.8GB
  • Task Manager did not correctly report barrierd.exe's memory usage, returning around 2.8K for Memory (active private working set)
  • RAMMap's Processes section listed hundreds to approximately a thousand instances of barrierd.exe.
  • Killing barrierd.exe at this point frees up around 2.4GB of RAM.
<!-- gh-comment-id:934046988 --> @PythonTryHard commented on GitHub (Oct 5, 2021): Reproducible on Windows 10 2004 (build 19041.1237) running Barrier `2.3.2`. Steps to reproduce: 1. Set up Barrier as server make sure it starts `barrierd.exe` on startup. Don't connect to anything to the server. 2. For physical 8GB of RAM, leave it for 5 days (yes, I mean it). Adjust the amount of RAM down for less waiting. 3. Inspect RAM usage with Task Manager and SysInternal RAMMap. Result: I didn't capture any screenshots because I was trying to save my system but from what I saw: - With 8 tabs of Firefox, Task Manager reported 7.6/7.8GB usage while a fresh boot would only consume to somewhere around 4.1/7.8GB - Task Manager did not correctly report `barrierd.exe`'s memory usage, returning around 2.8K for `Memory (active private working set)` - RAMMap's `Processes` section listed hundreds to approximately a thousand instances of `barrierd.exe`. - Killing `barrierd.exe` at this point frees up around 2.4GB of RAM.
Author
Owner

@elibroftw commented on GitHub (Sep 30, 2022):

This was insane. Barrier was taking up 3.52 GB of memory on my machine. I had to use RamMap to figure out barrier was the problem since there were many processes taking up 32K of memory. I was running 2.3.3 but I upgraded to the latest so we'll see if this is still an issue.

<!-- gh-comment-id:1263989702 --> @elibroftw commented on GitHub (Sep 30, 2022): This was insane. Barrier was taking up 3.52 GB of memory on my machine. I had to use RamMap to figure out barrier was the problem since there were many processes taking up 32K of memory. I was running 2.3.3 but I upgraded to the latest so we'll see if this is still an issue.
Author
Owner

@gkusmierz commented on GitHub (Oct 10, 2022):

Some time ago I tried to analyze this leak in Valgrind (I had a problem with Linux running all the time) but I fell because Barrier was too slow in one thread mode ...

It is probably problem with SSL implementation in app. Now I'm using server mode on my Windows laptop working 27/7 with unchecked options "Enable SSL" & "Require client certificate". Of course disable SSL only if you work on a trusted network...

<!-- gh-comment-id:1273007911 --> @gkusmierz commented on GitHub (Oct 10, 2022): Some time ago I tried to analyze this leak in Valgrind (I had a problem with Linux running all the time) but I fell because Barrier was too slow in one thread mode ... It is probably problem with SSL implementation in app. Now I'm using server mode on my Windows laptop working 27/7 with unchecked options "**Enable SSL**" & "**Require client certificate**". Of course disable SSL only if you work on a trusted network...
Author
Owner

@M-o-o commented on GitHub (Jul 27, 2023):

I have some kind of slow memory leak too, but mine is on barriers.exe. Using over 600MB after 5 days. I have SSL disabled already, so it can't be related to that.

<!-- gh-comment-id:1653409779 --> @M-o-o commented on GitHub (Jul 27, 2023): I have some kind of slow memory leak too, but mine is on barriers.exe. Using over 600MB after 5 days. I have SSL disabled already, so it can't be related to that.
Author
Owner

@jayktaylor commented on GitHub (Aug 20, 2023):

Just chiming in here to say that I noticed over the last week that my memory usage on my Windows 11 PC was hitting 72% (on a 32GB RAM machine) while doing nothing but simply watching Netflix on Firefox. This felt really off to me, and Task Manager wasn't very helpful, so I used RAMMap.

I discovered that there were hundreds of barriers.exe instances - most of which were using relatively small amounts of RAM, with a couple using much higher amounts. However, the sheer amount of instances indicated to me that there was a problem here, and that all of the instances combined might be eating the memory, so I uninstalled Barrier. My memory usage immediately dropped to 40%.

As I use this PC for compute-intensive tasks and gaming, I can't justify continuing to use Barrier while this memory issue exists. Happy to help with any debugging if required.

<!-- gh-comment-id:1685362688 --> @jayktaylor commented on GitHub (Aug 20, 2023): Just chiming in here to say that I noticed over the last week that my memory usage on my Windows 11 PC was hitting 72% (on a 32GB RAM machine) while doing nothing but simply watching Netflix on Firefox. This felt really off to me, and Task Manager wasn't very helpful, so I used [RAMMap](https://learn.microsoft.com/en-us/sysinternals/downloads/rammap). I discovered that there were hundreds of `barriers.exe` instances - most of which were using relatively small amounts of RAM, with a couple using much higher amounts. However, the sheer amount of instances indicated to me that there was a problem here, and that all of the instances combined might be eating the memory, so I uninstalled Barrier. My memory usage immediately dropped to 40%. As I use this PC for compute-intensive tasks and gaming, I can't justify continuing to use Barrier while this memory issue exists. Happy to help with any debugging if required.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#910
No description provided.