Barriers starts eating up all my RAM fast! #470
Comments
|
Thanks, memory leaks are known about. |
|
2.3.2-alpha was bad as well, using 2.3.1, it was good. So I started After that I don't really know how to proceed from there other than using the last good commit. |
|
Thanks, wasn't aware we had a regression with 2.3.2-alpha. |
|
It gets pretty terrible, I've hit almost 30GiB today... 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: EDIT2: EDIT3:
|
|
Before the a841b28 commit, 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 restart |
|
Had this issue several times recently. Mostly when waking the laptop with Running
|
|
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: |
|
Note that near 2019-12-09T02:06:59 the windows client started shutdown (via start menu) and the last message |
|
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 |
|
@fuhry |
The commit a841b28 changed the condition for removing job from processing. New flag MultiplexerJobStatus::continue_servicing become used instead of checking pointer for NULL. However for cases when TCPSocket::newJob() returns nullptr the behaviour changed: earlier the job was removed, but after change it is called again, since MultiplexerJobStatus equal to {true, nullptr} means "run this job again". This leads to problem with eating CPU and RAM on linux debauchee#470 There is similar windows problem, but not sure it is related. debauchee#552 Since it looks that the goal of a841b28 was only clarifying object ownership and not changing job deletion behaviour, this commit tries to get original behaviour and fix the bugs above by returning {false, nullptr} instead of {true, nullptr} when TCPSocket::newJob() returns nullptr.
|
I just experienced this today on 2.3.2 in |
|
thank you, am installing it now. :)
…On Thu, Mar 5, 2020 at 12:23 PM wjtk4444 ***@***.***> wrote:
@kreezxil <https://github.com/kreezxil>
#557 <#557> fixed it for me, try
building from source or using barrier-git from AUR
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#470?email_source=notifications&email_token=AA5TJCAZ2SCA2ZE54Q6PGETRF7U3PA5CNFSM4JBVIJ5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEN6LPTQ#issuecomment-595376078>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5TJCEA3KLKCDMC5GOZWT3RF7U3PANCNFSM4JBVIJ5A>
.
|
|
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? |
|
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 ***@***.***> wrote:
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?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#470 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5TJCFZCLVK7O3BAXWCSB3RHAGTRANCNFSM4JBVIJ5A>
.
|
|
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:
|
|
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. |
|
sounds like a firewall issue or an ip address changed. check those.
…On Tue, Mar 17, 2020 at 11:33 AM ascii78 ***@***.***> wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#470 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5TJCFZHP6XQRTPX3PFEQTRH6Q5NANCNFSM4JBVIJ5A>
.
|
|
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 |
|
lol, the bot should ping the person that opened it. the solution provided in here works, but is it in the main branch tho? |
|
#557 was merged, so yes it is in main branch and released as 2.3.3. |
|
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 ***@***.***> wrote:
#557 <#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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#470 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5TJCG3JHU5U3N3ETIT7KDSKZL63ANCNFSM4JBVIJ5A>
.
|
|
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. |
|
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. |
|
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. |
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
The text was updated successfully, but these errors were encountered: