Barrier: High memory usage - memory leak
Operating Systems
Server: Arch
Client: Arch
Barrier Version
2.1.0-Release000000
Steps to reproduce bug
- start barrier
- use barrier for a week, suspending my laptop (server) multiple times
- run out of RAM (barrier uses over 1GB of RAM)
Other info
- When did the problem start to occur? Slowly over a week.
- Is there a way to work around it? Yes, you can kill and restart barrier
- Does this bug prevent you from using Barrier entirely? No
Is this a known issue with release 2.1.0? If it isn't, I'll dig in to the code. ~For now I'll upgrade barrier to 2.1.1~ (that's an AUR version number, but barrier is still version 2.1) and monitor.
This pmap output seems to suggest that lots of memory is malloc'd but not free'd, since anon comes from malloc and mmap
pmap output:
sudo pmap -x 21458
21458: /usr/bin/barriers -f --no-tray --debug INFO --enable-crypto -c /tmp/Barrier.QgwrHs --address :24800
Address Kbytes RSS Dirty Mode Mapping
000055b7e47ce000 740 464 0 r-x-- barriers
000055b7e4a87000 28 28 28 r---- barriers
000055b7e4a8e000 16 4 4 rw--- barriers
000055b7e4a92000 4 4 4 rw--- [ anon ]
000055b7e535a000 339228 318560 318428 rw--- [ anon ]
00007f7924000000 80232 39856 39856 rw--- [ anon ]
00007f7928e5a000 50840 0 0 ----- [ anon ]
00007f792c000000 65532 32592 32592 rw--- [ anon ]
00007f792ffff000 4 0 0 ----- [ anon ]
00007f7930000000 65536 32504 32504 rw--- [ anon ]
00007f7934000000 131060 65108 65108 rw--- [ anon ]
00007f793bffd000 12 0 0 ----- [ anon ]
00007f793c000000 131072 65124 65124 rw--- [ anon ]
00007f7944000000 65528 32580 32580 rw--- [ anon ]
00007f7947ffe000 8 0 0 ----- [ anon ]
00007f7948000000 65524 32568 32568 rw--- [ anon ]
00007f794bffd000 12 0 0 ----- [ anon ]
00007f794c000000 65532 37820 37820 rw--- [ anon ]
00007f794ffff000 4 0 0 ----- [ anon ]
00007f7950000000 65528 32512 32512 rw--- [ anon ]
00007f7953ffe000 8 0 0 ----- [ anon ]
00007f7954000000 131060 75764 75764 rw--- [ anon ]
00007f795bffd000 12 0 0 ----- [ anon ]
00007f795c000000 131064 75464 75464 rw--- [ anon ]
00007f7963ffe000 8 0 0 ----- [ anon ]
00007f7964000000 65524 37564 37564 rw--- [ anon ]
00007f7967ffd000 12 0 0 ----- [ anon ]
00007f7968000000 65528 38104 38104 rw--- [ anon ]
00007f796bffe000 8 0 0 ----- [ anon ]
00007f796c000000 65528 38348 38348 rw--- [ anon ]
00007f796fffe000 8 0 0 ----- [ anon ]
00007f7970000000 65528 32568 32568 rw--- [ anon ]
00007f7973ffe000 8 0 0 ----- [ anon ]
00007f7974000000 131072 76232 76232 rw--- [ anon ]
00007f797c000000 131072 70076 70076 rw--- [ anon ]
00007f7984000000 65528 11644 11616 rw--- [ anon ]
00007f7987ffe000 8 0 0 ----- [ anon ]
00007f7988000000 65536 32524 32524 rw--- [ anon ]
00007f798c000000 65532 3096 3092 rw--- [ anon ]
00007f798ffff000 4 0 0 ----- [ anon ]
00007f7990fbb000 12 0 0 r---- libnss_files-2.28.so
00007f7990fbe000 28 0 0 r-x-- libnss_files-2.28.so
00007f7990fc5000 12 0 0 r---- libnss_files-2.28.so
00007f7990fc8000 4 0 0 r---- libnss_files-2.28.so
00007f7990fc9000 4 0 0 rw--- libnss_files-2.28.so
00007f7990fca000 24 0 0 rw--- [ anon ]
00007f7990fd0000 20 0 0 r-x-- libXfixes.so.3.1.0
00007f7990fd5000 2044 0 0 ----- libXfixes.so.3.1.0
00007f79911d4000 4 0 0 r---- libXfixes.so.3.1.0
00007f79911d5000 4 0 0 rw--- libXfixes.so.3.1.0
00007f79911d6000 36 0 0 r-x-- libXcursor.so.1.0.2
00007f79911df000 2044 0 0 ----- libXcursor.so.1.0.2
00007f79913de000 4 0 0 r---- libXcursor.so.1.0.2
00007f79913df000 4 0 0 rw--- libXcursor.so.1.0.2
00007f79913e0000 4 0 0 ----- [ anon ]
00007f79913e1000 8192 16 16 rw--- [ anon ]
00007f7991be1000 4 0 0 ----- [ anon ]
00007f7991be2000 8208 8 8 rw--- [ anon ]
00007f79923e6000 20 0 0 r-x-- libXdmcp.so.6.0.0
00007f79923eb000 2044 0 0 ----- libXdmcp.so.6.0.0
00007f79925ea000 4 0 0 r---- libXdmcp.so.6.0.0
00007f79925eb000 4 0 0 rw--- libXdmcp.so.6.0.0
00007f79925ec000 8 0 0 rw--- [ anon ]
00007f79925ee000 8 0 0 r-x-- libXau.so.6.0.0
00007f79925f0000 2048 0 0 ----- libXau.so.6.0.0
00007f79927f0000 4 0 0 r---- libXau.so.6.0.0
00007f79927f1000 4 0 0 rw--- libXau.so.6.0.0
00007f79927f2000 52 0 0 r---- libm-2.28.so
00007f79927ff000 644 0 0 r-x-- libm-2.28.so
00007f79928a0000 852 0 0 r---- libm-2.28.so
00007f7992975000 4 0 0 r---- libm-2.28.so
00007f7992976000 4 0 0 rw--- libm-2.28.so
00007f7992977000 36 0 0 r-x-- libXrender.so.1.3.0
00007f7992980000 2048 0 0 ----- libXrender.so.1.3.0
00007f7992b80000 4 4 0 r---- libXrender.so.1.3.0
00007f7992b81000 4 4 0 rw--- libXrender.so.1.3.0
00007f7992b82000 4 0 0 r---- libdl-2.28.so
00007f7992b83000 4 0 0 r-x-- libdl-2.28.so
00007f7992b84000 4 0 0 r---- libdl-2.28.so
00007f7992b85000 4 0 0 r---- libdl-2.28.so
00007f7992b86000 4 0 0 rw--- libdl-2.28.so
00007f7992b87000 156 64 0 r-x-- libxcb.so.1.1.0
00007f7992bae000 2048 0 0 ----- libxcb.so.1.1.0
00007f7992dae000 4 4 4 r---- libxcb.so.1.1.0
00007f7992daf000 4 0 0 rw--- libxcb.so.1.1.0
00007f7992db0000 8 0 0 rw--- [ anon ]
00007f7992db2000 136 0 0 r---- libc-2.28.so
00007f7992dd4000 1324 876 0 r-x-- libc-2.28.so
00007f7992f1f000 304 124 0 r---- libc-2.28.so
00007f7992f6b000 4 0 0 ----- libc-2.28.so
00007f7992f6c000 16 12 12 r---- libc-2.28.so
00007f7992f70000 8 8 8 rw--- libc-2.28.so
00007f7992f72000 16 8 8 rw--- [ anon ]
00007f7992f76000 12 0 0 r---- libgcc_s.so.1
00007f7992f79000 68 0 0 r-x-- libgcc_s.so.1
00007f7992f8a000 12 0 0 r---- libgcc_s.so.1
00007f7992f8d000 4 0 0 ----- libgcc_s.so.1
00007f7992f8e000 4 0 0 r---- libgcc_s.so.1
00007f7992f8f000 4 0 0 rw--- libgcc_s.so.1
00007f7992f90000 548 0 0 r---- libstdc++.so.6.0.25
00007f7993019000 736 584 0 r-x-- libstdc++.so.6.0.25
00007f79930d1000 244 16 0 r---- libstdc++.so.6.0.25
00007f799310e000 4 0 0 ----- libstdc++.so.6.0.25
00007f799310f000 48 32 28 r---- libstdc++.so.6.0.25
00007f799311b000 4 4 4 rw--- libstdc++.so.6.0.25
00007f799311c000 12 12 12 rw--- [ anon ]
00007f799311f000 468 0 0 r---- libcrypto.so.1.1
00007f7993194000 1660 1144 0 r-x-- libcrypto.so.1.1
00007f7993333000 564 236 0 r---- libcrypto.so.1.1
00007f79933c0000 176 120 120 r---- libcrypto.so.1.1
00007f79933ec000 8 8 8 rw--- libcrypto.so.1.1
00007f79933ee000 12 12 12 rw--- [ anon ]
00007f79933f1000 116 0 0 r---- libssl.so.1.1
00007f799340e000 304 268 0 r-x-- libssl.so.1.1
00007f799345a000 100 84 0 r---- libssl.so.1.1
00007f7993473000 4 0 0 ----- libssl.so.1.1
00007f7993474000 36 24 24 r---- libssl.so.1.1
00007f799347d000 16 16 16 rw--- libssl.so.1.1
00007f7993481000 60 60 0 r-x-- libXi.so.6.1.0
00007f7993490000 2048 0 0 ----- libXi.so.6.1.0
00007f7993690000 4 0 0 r---- libXi.so.6.1.0
00007f7993691000 4 4 4 rw--- libXi.so.6.1.0
00007f7993692000 8 0 0 rw--- [ anon ]
00007f7993694000 40 0 0 r-x-- libXrandr.so.2.2.0
00007f799369e000 2044 0 0 ----- libXrandr.so.2.2.0
00007f799389d000 4 4 0 r---- libXrandr.so.2.2.0
00007f799389e000 4 4 0 rw--- libXrandr.so.2.2.0
00007f799389f000 8 0 0 r-x-- libXinerama.so.1.0.0
00007f79938a1000 2044 0 0 ----- libXinerama.so.1.0.0
00007f7993aa0000 4 4 0 r---- libXinerama.so.1.0.0
00007f7993aa1000 4 4 0 rw--- libXinerama.so.1.0.0
00007f7993aa2000 68 64 0 r-x-- libXext.so.6.4.0
00007f7993ab3000 2044 0 0 ----- libXext.so.6.4.0
00007f7993cb2000 4 4 0 r---- libXext.so.6.4.0
00007f7993cb3000 4 4 0 rw--- libXext.so.6.4.0
00007f7993cb4000 112 0 0 r---- libX11.so.6.3.0
00007f7993cd0000 544 396 0 r-x-- libX11.so.6.3.0
00007f7993d58000 588 128 0 r---- libX11.so.6.3.0
00007f7993deb000 12 8 8 r---- libX11.so.6.3.0
00007f7993dee000 16 12 4 rw--- libX11.so.6.3.0
00007f7993df2000 20 0 0 r-x-- libXtst.so.6.1.0
00007f7993df7000 2044 0 0 ----- libXtst.so.6.1.0
00007f7993ff6000 4 0 0 r---- libXtst.so.6.1.0
00007f7993ff7000 4 0 0 rw--- libXtst.so.6.1.0
00007f7993ff8000 24 0 0 r---- libpthread-2.28.so
00007f7993ffe000 60 48 0 r-x-- libpthread-2.28.so
00007f799400d000 24 24 0 r---- libpthread-2.28.so
00007f7994013000 4 4 4 r---- libpthread-2.28.so
00007f7994014000 4 4 4 rw--- libpthread-2.28.so
00007f7994015000 24 4 4 rw--- [ anon ]
00007f7994065000 8 0 0 r---- ld-2.28.so
00007f7994067000 124 8 0 r-x-- ld-2.28.so
00007f7994086000 32 0 0 r---- ld-2.28.so
00007f799408e000 4 4 4 r---- ld-2.28.so
00007f799408f000 4 4 4 rw--- ld-2.28.so
00007f7994090000 4 0 0 rw--- [ anon ]
00007ffd999c2000 132 24 24 rw--- [ stack ]
00007ffd999f8000 12 0 0 r---- [ anon ]
00007ffd999fb000 8 4 0 r-x-- [ anon ]
---------------- ------- ------- -------
total kB 2159352 1185620 1180820
maxbla
All 16 comments
I made a debug build by changing -D CMAKE_BUILD_TYPE:STRING=Relaese to -D CMAKE_BUILD_TYPE:STRING=Debug in the pkgbuild. I also added set (CMAKE_BUILD_TYPE Debug) in src/barrier-2.1.1/CMakeLists.txt, but I don't think that had any effect.
I'm having trouble debugging this program. Valgrind gives an error valgrind: m_debuginfo/debuginfo.c:453 (discard_or_archive_DebugInfo): Assertion 'is_DebugInfo_active(di)' failed. Starting from main(), my debugger gets stuck at app.exec(). App is a QBarrierApplication, QBarrierApplication extends QApplication (from qt), and exec starts a blocking event loop that I can't step in.
What should I do?
maxbla
on 9 Oct 2018
Does this happen on the client or on the server or on both? Myself I haven't ever noticed high memory usage on a barrier server running on a mac, but this could be platform-specific issue.
p12tic
on 13 Oct 2018
I had the same problem on Windows 10. left the same release version running over the weekend. the computer wasn't actively in use.
In 3 days it was using 16gb of ram. (out of my 32gb).
You can see barriers.exe in procexp.exe constantly ticking up when the PC is idling. about 100kbyte/second.
edit: got it on linux now too after 30 days of uptime. had to kill both barrier and barrierc, as it was using 2.5 gb ram and 100% cpu.
sadly hard to debug, as the pc had run out of memory and wasn't responsive
edit2: the 2 PCs above are client/server, so both suffer from leaking.
datgame
on 11 Feb 2019
MacOS as well. It's the server, not the client.
May or may not be related, but I notice the client gets really slow, and pops up the "pasting" window for longer and longer length of time, until you stop and restart the server.
On my iMac Pro server it eats 64GB in a day. It doesn't seem to ever eat more than total physical memory (I have 64GB). MacOS does not crash, of course it swaps. Something seems to stop it at physical memory limit and so doesn't eat further virtual memory.
jtara
on 22 Feb 2019
I'm having this same issue with Ubuntu 18.04.2 and Barrier 2.2.0-snapshot-00000000
Over a couple of hours the memory usage for barriers creeps up to 300MB by the end of the day, it will be over 1GB if I don't stop/quit/kill Barrier.
I have noticed that when the memory use gets high the pointer on the client screen is real jittery - quitting and restarting Barrier fixes the problem.
I usually have to stop/restart Barrier a couple times a day due to this issue.
Please let me know if there are any log files or anything I can do to help you debug/solve this issue.
jdorner4
on 4 Jun 2019
There's a fix in Synergy for a TLS memory leak that isn't in Barrier yet. Can anyone disable SSL to see if the problem persists?
noisyshape
on 5 Jun 2019
I disabled TLS on both the server and client. This stopped the memory leak (or greatly reduced it to an acceptable level) for the barriers process. The barrier process' memory use is still growing, but also greatly reduced to an acceptable level.
jdorner4
on 5 Jun 2019
On my computer it happens that after some time being connected the cursor become completely unresponsive on client side.
I have to kill the process from another X session or from TTY. In general when this happens barrier uses 20% of CPU and a very high amount of RAM.
tallero
on 6 Aug 2019
This issue is still present on 2.3.2-RELEASE-00000000 (January 1, 2020)
After 1 day on the server the RAM usage went over 9GB, then the system started swapping so I had to kill barriers via TTY.
I did not check the client RAM usage before I killed it as well.
I thought that this might have something to do with sudden loss of connection and/or having the laptop (server) being put to sleep, but the RAM usage stays the same no matter what I try.
Client and server are both laptops using Arch with KDE.
nikola3244
on 3 Jan 2020
my workaround was to start using remote desktop instead :-)
the crazy ram usage and the problems with international keys and stuck mouse and ctrl/shift/win keys got too much.
datgame
on 3 Jan 2020
I can confirm this issue and I think, that it is the worst, when one of the clients either goes to sleep or the session is locked
my RAM usage goes over 21GB in just a few hours
EDIT: version 2.3.2-snapshot-0000....
zocker-160
on 28 Feb 2020
I can confirm this issue, barrier just grows until the complete system crashes. Which is a hard thing to do on my machine. Also the first time I saw a process consume 128G of memory in my life :-) It seems the memory leak starts whenever the opposing side (in my case a Windows 10 machine) disconnects. If I have some time I'll try to help debug it.
MathyV
on 4 Mar 2020
It looks to be duplicate of #470
I hope it was fixed in master with merging #557
galkinvv
on 6 May 2020
Just another data point, seeing apparent slow creep-up of memory use with barrier 2.3.3-release-bbd1accb, on Ubuntu 18.04:
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND
4500 user 20 0 1286,1m 5,9m 3,4m 469,0m S 0,0 0,1 4:13.64 barrier
Swap looks anomalously high.
mosteo
on 30 Sep 2020
@mosteo Thanks for yupur report. While the issue you described is similar - it seems to be unrelated.
The issue described here is about leaking background barriers/barrierc applications, and you mention barrier - a gui app for viewing status/configuration.
It is much less optimized (but of course shouldn't leak).
So if barrier app is leaking (the memory usage is increasing) - feel free to report a different issue.
galkinvv
on 30 Sep 2020
I see, sorry for the confusion.
mosteo
on 30 Sep 2020
Related issues
agilbertson1977
路
4Comments
TheCire
路
4Comments
shymega
路
4Comments
autotoxicus
路
4Comments
wjtk4444
路
4Comments
Most helpful comment
I can confirm this issue, barrier just grows until the complete system crashes. Which is a hard thing to do on my machine. Also the first time I saw a process consume 128G of memory in my life :-) It seems the memory leak starts whenever the opposing side (in my case a Windows 10 machine) disconnects. If I have some time I'll try to help debug it.