[GH-ISSUE #686] Linux server segmentation fault

gitea-mirror commented

2026-05-05 06:39:05 -06:00

Owner

Originally created by @iczero on GitHub (May 23, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/686

Operating Systems

Server: Ubuntu 20.04
Client: Ubuntu 20.04

Barrier Version

Commit dbd10820 (2.3.2-snapshot)

Steps to reproduce bug

Move mouse between screens

The bug seems to occur occasionally, without any noticeable pattern. I haven't been able to explicitly reproduce it yet. However, it has happened at least 50 times already.

Other info

When did the problem start to occur? When I started to use barrier
Is there a way to work around it? Yes, by running barriers in a while loop
Does this bug prevent you from using Barrier entirely? No, since you can run barriers in a while loop

This may be a duplicate of #362, but the error in dmesg was quite different.

Valgrind trace:

==956760== Invalid read of size 4
==956760==    at 0x4BF1964: ??? (in /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0)
==956760==    by 0x4AC465C: _XCopyEventCookie (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==956760==    by 0x4AB3D26: XPeekEvent (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==956760==    by 0x15B362: XWindowsImpl::XPeekEvent(_XDisplay*, _XEvent*) (XWindowsImpl.cpp:474)
==956760==    by 0x162664: XWindowsScreen::refreshKeyboard(_XEvent*) (XWindowsScreen.cpp:2014)
==956760==    by 0x15FF98: XWindowsScreen::handleSystemEvent(Event const&, void*) (XWindowsScreen.cpp:1263)
==956760==    by 0x16A7A9: TMethodEventJob<XWindowsScreen>::run(Event const&) (TMethodEventJob.h:69)
==956760==    by 0x130C55: EventQueue::dispatchEvent(Event const&) (EventQueue.cpp:282)
==956760==    by 0x13030E: EventQueue::loop() (EventQueue.cpp:128)
==956760==    by 0x152904: ServerApp::mainLoop() (ServerApp.cpp:787)
==956760==    by 0x152ECB: ServerApp::standardStartup(int, char**) (ServerApp.cpp:858)
==956760==    by 0x154A4A: standardStartupStatic(int, char**) (AppUtilUnix.cpp:33)
==956760==  Address 0x40 is not stack'd, malloc'd or (recently) free'd
==956760== 
==956760== 
==956760== Process terminating with default action of signal 11 (SIGSEGV)
==956760==  Access not within mapped region at address 0x40
==956760==    at 0x4BF1964: ??? (in /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0)
==956760==    by 0x4AC465C: _XCopyEventCookie (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==956760==    by 0x4AB3D26: XPeekEvent (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==956760==    by 0x15B362: XWindowsImpl::XPeekEvent(_XDisplay*, _XEvent*) (XWindowsImpl.cpp:474)
==956760==    by 0x162664: XWindowsScreen::refreshKeyboard(_XEvent*) (XWindowsScreen.cpp:2014)
==956760==    by 0x15FF98: XWindowsScreen::handleSystemEvent(Event const&, void*) (XWindowsScreen.cpp:1263)
==956760==    by 0x16A7A9: TMethodEventJob<XWindowsScreen>::run(Event const&) (TMethodEventJob.h:69)
==956760==    by 0x130C55: EventQueue::dispatchEvent(Event const&) (EventQueue.cpp:282)
==956760==    by 0x13030E: EventQueue::loop() (EventQueue.cpp:128)
==956760==    by 0x152904: ServerApp::mainLoop() (ServerApp.cpp:787)
==956760==    by 0x152ECB: ServerApp::standardStartup(int, char**) (ServerApp.cpp:858)
==956760==    by 0x154A4A: standardStartupStatic(int, char**) (AppUtilUnix.cpp:33)

gdb backtrace (more or less the same):

#0  XInputCopyCookie (dpy=<optimized out>, out=0x7fffffffd020, in=0x7fffffffd150) at ../../src/XExtInt.c:1490
#1  XInputCopyCookie (dpy=<optimized out>, in=0x7fffffffd150, out=0x7fffffffd020) at ../../src/XExtInt.c:1436
#2  0x00007ffff7c9265d in _XCopyEventCookie (dpy=dpy@entry=0x5555556e39b0, in=in@entry=0x7fffffffd150, out=out@entry=0x7fffffffd020) at ../../src/XlibInt.c:729
#3  0x00007ffff7c81d27 in XPeekEvent (dpy=0x5555556e39b0, event=0x7fffffffd150) at ../../src/PeekEvent.c:48
#4  0x00005555555a7363 in XWindowsImpl::XPeekEvent (this=0x5555556e3650, display=0x5555556e39b0, event_return=0x7fffffffd150) at /home/iczero/opt/barrier/src/lib/platform/XWindowsImpl.cpp:474
#5  0x00005555555ae665 in XWindowsScreen::refreshKeyboard (this=0x5555556e3670, event=0x555555710e60) at /home/iczero/opt/barrier/src/lib/platform/XWindowsScreen.cpp:2014
#6  0x00005555555abf99 in XWindowsScreen::handleSystemEvent (this=0x5555556e3670, event=...) at /home/iczero/opt/barrier/src/lib/platform/XWindowsScreen.cpp:1263
#7  0x00005555555b67aa in TMethodEventJob<XWindowsScreen>::run (this=0x555555710ae0, event=...) at /home/iczero/opt/barrier/src/./lib/base/TMethodEventJob.h:69
#8  0x000055555557cc56 in EventQueue::dispatchEvent (this=0x7fffffffd920, event=...) at /home/iczero/opt/barrier/src/lib/base/EventQueue.cpp:282
#9  0x000055555557c30f in EventQueue::loop (this=0x7fffffffd920) at /home/iczero/opt/barrier/src/lib/base/EventQueue.cpp:128
#10 0x000055555559e905 in ServerApp::mainLoop (this=0x7fffffffd720) at /home/iczero/opt/barrier/src/lib/barrier/ServerApp.cpp:787
#11 0x000055555559eecc in ServerApp::standardStartup (this=0x7fffffffd720, argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/lib/barrier/ServerApp.cpp:858
#12 0x00005555555a0a4b in standardStartupStatic (argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/lib/barrier/unix/AppUtilUnix.cpp:33
#13 0x000055555559ecd8 in ServerApp::runInner (this=0x7fffffffd720, argc=12, argv=0x7fffffffdcd8, outputter=0x0, startup=0x5555555a0a0b <standardStartupStatic(int, char**)>)
    at /home/iczero/opt/barrier/src/lib/barrier/ServerApp.cpp:831
#14 0x00005555555a0aa2 in AppUtilUnix::run (this=0x7fffffffd760, argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/lib/barrier/unix/AppUtilUnix.cpp:39
#15 0x000055555559987a in App::run (this=0x7fffffffd720, argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/lib/barrier/App.cpp:109
#16 0x00005555555721af in main (argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/cmd/barriers/barriers.cpp:56

edit: installed debug symbols for libx11 and libxi6, updated backtrace

Originally created by @iczero on GitHub (May 23, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/686 ### Operating Systems ### Server: Ubuntu 20.04 Client: Ubuntu 20.04 ### Barrier Version ### Commit dbd10820 (2.3.2-snapshot) ### Steps to reproduce bug ### 1. Move mouse between screens The bug seems to occur occasionally, without any noticeable pattern. I haven't been able to explicitly reproduce it yet. However, it has happened at least 50 times already. ### Other info ### * When did the problem start to occur? When I started to use barrier * Is there a way to work around it? Yes, by running barriers in a while loop * Does this bug prevent you from using Barrier entirely? No, since you can run barriers in a while loop This may be a duplicate of #362, but the error in dmesg was quite different. Valgrind trace: ``` ==956760== Invalid read of size 4 ==956760== at 0x4BF1964: ??? (in /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0) ==956760== by 0x4AC465C: _XCopyEventCookie (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) ==956760== by 0x4AB3D26: XPeekEvent (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) ==956760== by 0x15B362: XWindowsImpl::XPeekEvent(_XDisplay*, _XEvent*) (XWindowsImpl.cpp:474) ==956760== by 0x162664: XWindowsScreen::refreshKeyboard(_XEvent*) (XWindowsScreen.cpp:2014) ==956760== by 0x15FF98: XWindowsScreen::handleSystemEvent(Event const&, void*) (XWindowsScreen.cpp:1263) ==956760== by 0x16A7A9: TMethodEventJob<XWindowsScreen>::run(Event const&) (TMethodEventJob.h:69) ==956760== by 0x130C55: EventQueue::dispatchEvent(Event const&) (EventQueue.cpp:282) ==956760== by 0x13030E: EventQueue::loop() (EventQueue.cpp:128) ==956760== by 0x152904: ServerApp::mainLoop() (ServerApp.cpp:787) ==956760== by 0x152ECB: ServerApp::standardStartup(int, char**) (ServerApp.cpp:858) ==956760== by 0x154A4A: standardStartupStatic(int, char**) (AppUtilUnix.cpp:33) ==956760== Address 0x40 is not stack'd, malloc'd or (recently) free'd ==956760== ==956760== ==956760== Process terminating with default action of signal 11 (SIGSEGV) ==956760== Access not within mapped region at address 0x40 ==956760== at 0x4BF1964: ??? (in /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0) ==956760== by 0x4AC465C: _XCopyEventCookie (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) ==956760== by 0x4AB3D26: XPeekEvent (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) ==956760== by 0x15B362: XWindowsImpl::XPeekEvent(_XDisplay*, _XEvent*) (XWindowsImpl.cpp:474) ==956760== by 0x162664: XWindowsScreen::refreshKeyboard(_XEvent*) (XWindowsScreen.cpp:2014) ==956760== by 0x15FF98: XWindowsScreen::handleSystemEvent(Event const&, void*) (XWindowsScreen.cpp:1263) ==956760== by 0x16A7A9: TMethodEventJob<XWindowsScreen>::run(Event const&) (TMethodEventJob.h:69) ==956760== by 0x130C55: EventQueue::dispatchEvent(Event const&) (EventQueue.cpp:282) ==956760== by 0x13030E: EventQueue::loop() (EventQueue.cpp:128) ==956760== by 0x152904: ServerApp::mainLoop() (ServerApp.cpp:787) ==956760== by 0x152ECB: ServerApp::standardStartup(int, char**) (ServerApp.cpp:858) ==956760== by 0x154A4A: standardStartupStatic(int, char**) (AppUtilUnix.cpp:33) ``` gdb backtrace (more or less the same): ``` #0 XInputCopyCookie (dpy=<optimized out>, out=0x7fffffffd020, in=0x7fffffffd150) at ../../src/XExtInt.c:1490 #1 XInputCopyCookie (dpy=<optimized out>, in=0x7fffffffd150, out=0x7fffffffd020) at ../../src/XExtInt.c:1436 #2 0x00007ffff7c9265d in _XCopyEventCookie (dpy=dpy@entry=0x5555556e39b0, in=in@entry=0x7fffffffd150, out=out@entry=0x7fffffffd020) at ../../src/XlibInt.c:729 #3 0x00007ffff7c81d27 in XPeekEvent (dpy=0x5555556e39b0, event=0x7fffffffd150) at ../../src/PeekEvent.c:48 #4 0x00005555555a7363 in XWindowsImpl::XPeekEvent (this=0x5555556e3650, display=0x5555556e39b0, event_return=0x7fffffffd150) at /home/iczero/opt/barrier/src/lib/platform/XWindowsImpl.cpp:474 #5 0x00005555555ae665 in XWindowsScreen::refreshKeyboard (this=0x5555556e3670, event=0x555555710e60) at /home/iczero/opt/barrier/src/lib/platform/XWindowsScreen.cpp:2014 #6 0x00005555555abf99 in XWindowsScreen::handleSystemEvent (this=0x5555556e3670, event=...) at /home/iczero/opt/barrier/src/lib/platform/XWindowsScreen.cpp:1263 #7 0x00005555555b67aa in TMethodEventJob<XWindowsScreen>::run (this=0x555555710ae0, event=...) at /home/iczero/opt/barrier/src/./lib/base/TMethodEventJob.h:69 #8 0x000055555557cc56 in EventQueue::dispatchEvent (this=0x7fffffffd920, event=...) at /home/iczero/opt/barrier/src/lib/base/EventQueue.cpp:282 #9 0x000055555557c30f in EventQueue::loop (this=0x7fffffffd920) at /home/iczero/opt/barrier/src/lib/base/EventQueue.cpp:128 #10 0x000055555559e905 in ServerApp::mainLoop (this=0x7fffffffd720) at /home/iczero/opt/barrier/src/lib/barrier/ServerApp.cpp:787 #11 0x000055555559eecc in ServerApp::standardStartup (this=0x7fffffffd720, argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/lib/barrier/ServerApp.cpp:858 #12 0x00005555555a0a4b in standardStartupStatic (argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/lib/barrier/unix/AppUtilUnix.cpp:33 #13 0x000055555559ecd8 in ServerApp::runInner (this=0x7fffffffd720, argc=12, argv=0x7fffffffdcd8, outputter=0x0, startup=0x5555555a0a0b <standardStartupStatic(int, char**)>) at /home/iczero/opt/barrier/src/lib/barrier/ServerApp.cpp:831 #14 0x00005555555a0aa2 in AppUtilUnix::run (this=0x7fffffffd760, argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/lib/barrier/unix/AppUtilUnix.cpp:39 #15 0x000055555559987a in App::run (this=0x7fffffffd720, argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/lib/barrier/App.cpp:109 #16 0x00005555555721af in main (argc=12, argv=0x7fffffffdcd8) at /home/iczero/opt/barrier/src/cmd/barriers/barriers.cpp:56 ``` edit: installed debug symbols for libx11 and libxi6, updated backtrace

gitea-mirror closed this issue

2026-05-05 06:39:08 -06:00

gitea-mirror commented

2026-05-05 06:39:12 -06:00

Author

Owner

@iczero commented on GitHub (Jun 18, 2020):

It seems this only really happens in conjunction with another issue that seems to affect xinput. I probably have a broken configuration somewhere.

@iczero commented on GitHub (Jun 18, 2020): It seems this only really happens in conjunction with another issue that seems to affect xinput. I probably have a broken configuration somewhere.

gitea-mirror commented

2026-05-05 06:39:15 -06:00

Author

Owner

@paul-theorem commented on GitHub (Jul 27, 2020):

I'm interested in a solution here. I'm using xubuntu 20.04, and i've used snap to install latest stable(2.3.2-13), and edge (2.3.3-2) - both same failure - "segfault at 1a1" ... "Code: Bad RIP value."

I'm happy to install an earlier version. I have had great luck using barrier on xubuntu 18.04, and Mac OS. I've actually become dependent on it. I've been waiting for a fix - but at this point i think i may need to back my desktop off to 18.04 just to get barrier back.

Any workaround is appreciated.

@paul-theorem commented on GitHub (Jul 27, 2020): I'm interested in a solution here. I'm using xubuntu 20.04, and i've used snap to install latest stable(2.3.2-13), and edge (2.3.3-2) - both same failure - "segfault at 1a1" ... "Code: Bad RIP value." I'm happy to install an earlier version. I have had great luck using barrier on xubuntu 18.04, and Mac OS. I've actually become dependent on it. I've been waiting for a fix - but at this point i think i may need to back my desktop off to 18.04 just to get barrier back. Any workaround is appreciated.

gitea-mirror commented

2026-05-05 06:39:18 -06:00

Author

Owner

@iczero commented on GitHub (Aug 1, 2020):

@paul-theorem Are you by chance using ibus?

If it doesn't segfault immediately after launch you could just run the main barrier server process in a while loop, something like:

while sleep 5; do barriers -f --no-tray --debug DEBUG --name desktop --enable-crypto -c path/to/barriers.conf --address :24800; done

@iczero commented on GitHub (Aug 1, 2020): @paul-theorem Are you by chance using ibus? If it doesn't segfault immediately after launch you could just run the main barrier server process in a while loop, something like: ```bash while sleep 5; do barriers -f --no-tray --debug DEBUG --name desktop --enable-crypto -c path/to/barriers.conf --address :24800; done ```

gitea-mirror commented

2026-05-05 06:39:21 -06:00

Author

Owner

@paul-theorem commented on GitHub (Aug 2, 2020):

@iczero how do i know if i am using ibus? I'm running xubuntu 20.04. Barrier works fine on xubuntu 18.04. I did post an strace log to the other issue:
https://github.com/debauchee/barrier/issues/362

Both issues seem to mention "bad rip value" which feels like the root cause here.

@paul-theorem commented on GitHub (Aug 2, 2020): @iczero how do i know if i am using ibus? I'm running xubuntu 20.04. Barrier works fine on xubuntu 18.04. I did post an strace log to the other issue: https://github.com/debauchee/barrier/issues/362 Both issues seem to mention "bad rip value" which feels like the root cause here.

gitea-mirror commented

2026-05-05 06:39:23 -06:00

Author

Owner

@definite commented on GitHub (Oct 17, 2021):

It seems to happen in fedora as well
Bug 2006514 - [abrt] barrier: count_bits(): barriers killed by SIGSEGV

The attachment section in the bug have more details.

@iczero I am using IBus, yet the bug does not seem to bit me. :-)
The workaround from #362 is using barriers and barrierc (run as command line).
I do rely on them instead of using GUI.

@paul-theorem IBus is an input method framework, so you probably not using it if you did not use east Asian languages.

@definite commented on GitHub (Oct 17, 2021): It seems to happen in fedora as well [Bug 2006514 - [abrt] barrier: count_bits(): barriers killed by SIGSEGV](https://bugzilla.redhat.com/show_bug.cgi?id=2006514) The attachment section in the bug have more details. @iczero I am using IBus, yet the bug does not seem to bit me. :-) The workaround from #362 is using barriers and barrierc (run as command line). I do rely on them instead of using GUI. @paul-theorem IBus is an input method framework, so you probably not using it if you did not use east Asian languages.

gitea-mirror commented

2026-05-05 06:39:25 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Apr 9, 2023):

What does closing a segfault type of bug as not planned mean exactly?

@brianjmurrell commented on GitHub (Apr 9, 2023): What does closing a segfault type of bug as _not planned_ mean exactly?

gitea-mirror commented

2026-05-05 06:39:27 -06:00

Author

Owner

@iczero commented on GitHub (Apr 9, 2023):

@brianjmurrell No progress has been made on this issue since I've opened it (3 years ago) and it doesn't seem like it's reproducible. If you're still interested then I can reopen the issue.

@iczero commented on GitHub (Apr 9, 2023): @brianjmurrell No progress has been made on this issue since I've opened it (3 years ago) and it doesn't seem like it's reproducible. If you're still interested then I can reopen the issue.

gitea-mirror commented

2026-05-05 06:39:29 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Apr 10, 2023):

No, I don't suppose it needs reopening. "Unplanned" just seems an odd category to close such a ticket I suppose. "Cannot reproduce" or something along those lines seems more straight-forward/accurate IMHO. But no matter.

@brianjmurrell commented on GitHub (Apr 10, 2023): No, I don't suppose it needs reopening. "Unplanned" just seems an odd category to close such a ticket I suppose. "Cannot reproduce" or something along those lines seems more straight-forward/accurate IMHO. But no matter.

gitea-mirror commented

2026-05-05 06:39:30 -06:00

Author

Owner

@iczero commented on GitHub (Apr 10, 2023):

The only options I got when closing were "not planned" and "complete". Maybe it's a bug with GitHub? It used to be that you could just close a ticket without giving a reason at all.

@iczero commented on GitHub (Apr 10, 2023): The only options I got when closing were "not planned" and "complete". Maybe it's a bug with GitHub? It used to be that you could just close a ticket without giving a reason at all.

gitea-mirror commented

2026-05-05 06:39:34 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Apr 10, 2023):

Hrm. I see. Thanks for the explanation. That does seem like quite a limited choice to provide if making a choice is required. I wonder if it's worth opening a support ticket with GitHub about.

@brianjmurrell commented on GitHub (Apr 10, 2023): Hrm. I see. Thanks for the explanation. That does seem like quite a limited choice to provide if making a choice is required. I wonder if it's worth [opening a support ticket](https://docs.github.com/en/support/contacting-github-support/creating-a-support-ticket) with GitHub about.

gitea-mirror commented

2026-05-05 06:39:35 -06:00

Author

Owner

@iczero commented on GitHub (Apr 10, 2023):

I guess "not planned" is supposed to be the close reason for everything that isn't resolved? Unreproducible ends up being "not planned until someone can reliably get it to crash", perhaps, rather than a strict WONTFIX.

@iczero commented on GitHub (Apr 10, 2023): I guess "not planned" is supposed to be the close reason for everything that isn't resolved? Unreproducible ends up being "not planned until someone can reliably get it to crash", perhaps, rather than a strict WONTFIX.

Rows
Columns

[GH-ISSUE #686] Linux server segmentation fault #546

Operating Systems

Barrier Version

Steps to reproduce bug

Other info