mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #470] Barriers starts eating up all my RAM fast! #364
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#364
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @wari on GitHub (Oct 17, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/470
Operating Systems
Server: Manjaro Linux
Client: Mac OS Catalina/Windows 10 (Not the problem)
Barrier Version
2.3.2 Stable Release as well as tested on current git master.
Steps to reproduce bug
Just run barrier as a server (no TLS configured), Click on start.
I notice that barrier runs hot on all my CPUs and quickly east up the RAM until the computer freezes. Below is a snapshot from
htopbefore I killed it, it was taking up 51% of my 16GB RAM and CPU jumps from 100% to 500%++.Other info
@AdrianKoshka commented on GitHub (Oct 17, 2019):
Thanks, memory leaks are known about.
@wari commented on GitHub (Oct 21, 2019):
2.3.2-alpha was bad as well, using 2.3.1, it was good. So I started
git bisectand I got:After that I don't really know how to proceed from there other than using the last good commit.
@AdrianKoshka commented on GitHub (Oct 21, 2019):
Thanks, wasn't aware we had a regression with 2.3.2-alpha.
@wjtk4444 commented on GitHub (Oct 23, 2019):
It gets pretty terrible, I've hit almost 30GiB today...
I think it happens after disconnecting from a client, but further tests are needed. Tried both barrier-headless 2.3.1 and current git master.
This gif looks pretty hilarious when sized down to fit a github comment, lol. Click on it to see the full size for more readability. This is x1 speed, it leaks at around ~25MiB/s.
EDIT:
Pretty sure it didn't happen ~2 weeks ago (before I updated my system), so on whatever version Arch Linux repositories had by then 2.3.1?). There's a chance that I misread 2.3.2-1 for 2.3.1 when I reported earlier in that post.
I'm basing my assumptions on the fact, that I had my pc running for a good two or three weeks straight (with
barriersrunning all the time) and I've connected to and disconnected from clients at least 2 times a day during that period. If previous version was leaking on disconnect, it'd crash my pc numerous times.EDIT2:
It seems like using the gui to start barrier rather than just callingbarriersfrom a script prevents the leak from happening. I tried it only a few times, but always the same thing happens.EDIT3:
Nope, it started leaking again even after being started using the GUI. Not everytime, but it still happens.
@wari commented on GitHub (Oct 29, 2019):
Before the
a841b2858fcommit, the CPU does not hit more than 9% for me, and the RAM consumption is manageable, starting at 9K and then going up to 200MB after a week. I can easily restartbarriers. When I apply that patch, CPU consumption immediately goes up very high and I can hit 8GB of RSS memory within 7 minutes. So even if there's a memory leak, at least it's a "sane" creep up, not like what it is now.@maxiberta commented on GitHub (Nov 21, 2019):
Had this issue several times recently. Mostly when waking the laptop with
barriersfrom sleep. Last timebarriersRSS reached 17GB in a matter of minutes, and kept growing fast. Managed to run a quickstrace(viasudo htop) and captured a screenshot of each of the 3 threads. One thread was stuck, while the two other were in a seemingly infinite loop. Hope it helps.Running
barriersnap on channeledge, Ubuntu 19.10.@galkinvv commented on GitHub (Dec 19, 2019):
Same problem appaears for me while using 2.3.2 with ssl disabled in config. I'm not sure if it appears while ssl is used.
Eaelier in this issue the bisection was done and it showed
I used another methos and it confirms that issue is related to SocketMultiplexerJob. I' d attached gdb to the barriers process eating Memory & 150% of cpu core and found a callstack of active threads.
Thread 3 (Thread 0x7f6b5e071700 (LWP 32346)): EATS 100% of core
Thread 2 (Thread 0x7f6b5e872700 (LWP 32345)): Does not eat cpu
Thread 1 (Thread 0x7f6b5e8bef80 (LWP 32344)): EATS 50% of core
log before barriers gone to "bad loop" state:
@galkinvv commented on GitHub (Dec 19, 2019):
Note that near 2019-12-09T02:06:59 the windows client started shutdown (via start menu) and the last message
accepted client connectionlooks to be send by a client process that appears only for 1-2 seconds on windows after logoff and before shutdown. So this may be issue with "client suddenly disappeared during connection".@fuhry commented on GitHub (Jan 29, 2020):
I can confirm this is affecting me with SSL enabled, and the circumstances leading up to the extreme memory leak are similar to what @galkinvv describes. For now I'm running
barriersunder systemd as a user service with memory limited to 128MB.@wjtk4444 commented on GitHub (Jan 29, 2020):
@fuhry
Now that's pretty smart, did you run into any problems when the limit is reached? I expect at least clipboard sharing to stop working.
@kreezxil commented on GitHub (Mar 5, 2020):
I just experienced this today on 2.3.2 in
@wjtk4444 commented on GitHub (Mar 5, 2020):
@kreezxil
https://github.com/debauchee/barrier/pull/557 fixed it for me, try building from source or using barrier-git from AUR
@kreezxil commented on GitHub (Mar 5, 2020):
thank you, am installing it now. :)
On Thu, Mar 5, 2020 at 12:23 PM wjtk4444 notifications@github.com wrote:
@chewi commented on GitHub (Mar 11, 2020):
This happened to my Linux system when my Windows 10 client started rebooting for updates. It's pretty bad so I'd like to patch the Gentoo Linux package I just published but perhaps it warrants a new release?
@kreezxil commented on GitHub (Mar 12, 2020):
I second that. Since installing the git version of barriers I am no longer
having the problem. I personally recommend that all package manager upgrade
to this one.
On Wed, Mar 11, 2020 at 5:33 PM James Le Cuirot notifications@github.com
wrote:
@galkinvv commented on GitHub (Mar 12, 2020):
I agree. This issue lacks the example of a description bad case of user-visible behaviour due to this problem. For me it was recent-work-loss situation:
@ascii78 commented on GitHub (Mar 17, 2020):
This fixed exactly the problem on my setup with manjaro server and windows 10 virtual with gpu passthrough. Stopped working today, my guess is that a windows update changed something.
@kreezxil commented on GitHub (Mar 18, 2020):
sounds like a firewall issue or an ip address changed. check those.
On Tue, Mar 17, 2020 at 11:33 AM ascii78 notifications@github.com wrote:
@fuhry commented on GitHub (Apr 15, 2020):
@galkinvv I have pretty standard OOM-killer settings and still did not see
barriersget properly selected for reaping by the OOM killer when the memory leak triggered.Anyways, the issue is resolved since I integrated the patch from #557 into my
PKGBUILD. Thank you!@github-actions[bot] commented on GitHub (Oct 15, 2020):
Is this issue still an issue for you? Please do comment and let us know! Alternatively, you may close the issue yourself if it is no longer an problem
@kreezxil commented on GitHub (Oct 15, 2020):
lol, the bot should ping the person that opened it. the solution provided in here works, but is it in the main branch tho?
@galkinvv commented on GitHub (Oct 15, 2020):
#557 was merged, so yes it is in main branch and released as 2.3.3.
Since this thread stopped getting reports of such problem since that - I think this should be closed
@kreezxil commented on GitHub (Oct 15, 2020):
i would say it should've been closed as soon as that patch was merged to
resolve it. As any recurrence of the issue would in effect be a new unique
issue that seemed similar that therefore should be raised as a new issue.
This thread is already confused.
On Wed, Oct 14, 2020 at 9:20 PM Vasily Galkin notifications@github.com
wrote:
@darmbrust commented on GitHub (Nov 17, 2020):
Just adding some comments to help searchers....
For me, I would notice (what I hope) is this issue, with my barrier server running on Linux / KDE - when I would mouse over to my windows 10 client, and click the shutdown button. It would immediately hang my mouse / keyboard, as barrier still seemed to think they were on the windows system, that was now disconnected.
I could still Ctrl+Alt+F key over to a command console, notice that barriers was eating CPU, and growing RAM usage... and kill -9 - at which point my KDE session would recover (though KDE would warn of various things being restarted)
I'll upgrade from 2.3.2 in hopes that the issue goes away with the fix above...
Thanks for maintaining this opensource tool, by the way. I missed it when the old one went paid.... until I found it here.
@darmbrust commented on GitHub (Nov 17, 2020):
This hasn't been brought into the Ubuntu package manager yet, unfortunately, for the LTS releases. I've filed a bug there, hoping that they will backport it. There is a PPA with the 2.3.3 release, which I'm testing now.
@bjohas commented on GitHub (Dec 11, 2020):
I had the same problem with installing on Ubuntu 20.04 with apt (barrier 2.3.2). Installing the snap gives barrier 2.3.3.