Bug 1370306 - Synergy server is hanging on Fedora 24 within XWindowsUtil::getCurrentTime()
Summary: Synergy server is hanging on Fedora 24 within XWindowsUtil::getCurrentTime()
Alias: None
Product: Fedora
Classification: Fedora
Component: synergy
Version: 24
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Christian Krause
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-08-25 22:26 UTC by Gustavo Luiz Duarte
Modified: 2017-08-08 16:48 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2017-08-08 16:48:39 UTC

Attachments (Terms of Use)

Description Gustavo Luiz Duarte 2016-08-25 22:26:54 UTC
Description of problem:
Very frequently synergys is hanging and I have to kill it with SIGKILL (SIGTERM won't kill it). No apparent reason seems to show on the log.

Setting the debug level to DEBUG2 seems to help.

Looks like every time it hangs it is stuck within XWindowsUtil::getCurrentTime(). Here is an example of a gdb backtrace when it is stuck:

(gdb) bt
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f8ffd509430 in _XReply (dpy=dpy@entry=0x56543cb95b10, rep=rep@entry=0x7ffe1c6e0f80, extra=extra@entry=0, discard=discard@entry=1) at xcb_io.c:624
#2  0x00007f8ffd504cf0 in XSync (dpy=0x56543cb95b10, discard=discard@entry=0) at Sync.c:44
#3  0x000056543c884d8c in XWindowsUtil::ErrorLock::install (this=0x7ffe1c6e1070, 
    handler=0x56543c884960 <XWindowsUtil::ErrorLock::ignoreHandler(_XDisplay*, XErrorEvent*, void*)>, data=0x0)
    at /usr/src/debug/synergy-1.7.6-stable/src/lib/platform/XWindowsUtil.cpp:1754
#4  0x000056543c884e5c in XWindowsUtil::getWindowProperty (display=0x56543cb95b10, window=20971524, property=622, data=data@entry=0x0, type=type@entry=0x7ffe1c6e10f0, 
    format=format@entry=0x0, deleteProperty=false) at /usr/src/debug/synergy-1.7.6-stable/src/lib/platform/XWindowsUtil.cpp:1306
#5  0x000056543c88b4ed in XWindowsScreenSaver::isXScreenSaver (this=<optimized out>, w=<optimized out>)
    at /usr/src/debug/synergy-1.7.6-stable/src/lib/platform/XWindowsScreenSaver.cpp:381
#6  0x000056543c88c460 in XWindowsScreenSaver::handleXEvent (this=0x56543cba9c90, xevent=xevent@entry=0x56543cbb1938)
    at /usr/src/debug/synergy-1.7.6-stable/src/lib/platform/XWindowsScreenSaver.cpp:189
#7  0x000056543c87e358 in XWindowsScreen::handleSystemEvent (this=0x56543cb94670, event=...) at /usr/src/debug/synergy-1.7.6-stable/src/lib/platform/XWindowsScreen.cpp:1261
#8  0x000056543c86582d in EventQueue::dispatchEvent (this=0x7ffe1c6e1620, event=...) at /usr/src/debug/synergy-1.7.6-stable/src/lib/base/EventQueue.cpp:271
#9  0x000056543c867f7f in EventQueue::loop (this=0x7ffe1c6e1620) at /usr/src/debug/synergy-1.7.6-stable/src/lib/base/EventQueue.cpp:129
#10 0x000056543c8724b0 in ServerApp::mainLoop (this=0x7ffe1c6e1580) at /usr/src/debug/synergy-1.7.6-stable/src/lib/synergy/ServerApp.cpp:764
#11 0x000056543c873ca5 in App::daemonMainLoop (this=0x7ffe1c6e1580) at /usr/src/debug/synergy-1.7.6-stable/src/lib/synergy/App.cpp:146
#12 0x000056543c86448a in ArchDaemonUnix::daemonize (this=<optimized out>, name=<optimized out>, func=0x56543c86f620 <daemonMainLoopStatic(int, char const**)>)
---Type <return> to continue, or q <return> to quit---
    at /usr/src/debug/synergy-1.7.6-stable/src/lib/arch/unix/ArchDaemonUnix.cpp:129
#13 0x000056543c86fbad in ServerApp::runInner (this=0x7ffe1c6e1580, argc=3, argv=0x7ffe1c6e1b58, outputter=0x0, startup=0x56543c874660 <standardStartupStatic(int, char**)>)
    at /usr/src/debug/synergy-1.7.6-stable/src/lib/synergy/ServerApp.cpp:811
#14 0x000056543c874499 in App::run (this=0x7ffe1c6e1580, argc=3, argv=0x7ffe1c6e1b58) at /usr/src/debug/synergy-1.7.6-stable/src/lib/synergy/App.cpp:118
#15 0x000056543c85d185 in main (argc=3, argv=0x7ffe1c6e1b58) at /usr/src/debug/synergy-1.7.6-stable/src/cmd/synergys/synergys.cpp:49

And thread #4 is the one stuck within XWindowsUtil::getCurrentTime():

(gdb) t 4
[Switching to thread 4 (Thread 0x7f8ff522a700 (LWP 9671))]
#0  0x00007f8ffbf2032d in poll () at ../sysdeps/unix/syscall-template.S:84
(gdb) bt
#0  0x00007f8ffbf2032d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f8ff918ff80 in poll (__timeout=-1, __nfds=1, __fds=0x7f8ff5229a30) at /usr/include/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0x56543cb96d60, cond=cond@entry=0x56543cb96da0, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:459
#3  0x00007f8ff9191b79 in xcb_wait_for_event (c=0x56543cb96d60) at xcb_in.c:693
#4  0x00007f8ffd50903b in _XReadEvents (dpy=dpy@entry=0x56543cb95b10) at xcb_io.c:401
#5  0x00007f8ffd4f062e in XIfEvent (dpy=dpy@entry=0x56543cb95b10, event=event@entry=0x7f8ff5229c70, 
    predicate=predicate@entry=0x56543c8848f0 <XWindowsUtil::propertyNotifyPredicate(_XDisplay*, _XEvent*, char*)>, arg=arg@entry=0x7f8ff5229bd0 "\004") at IfEvent.c:68
#6  0x000056543c884a7b in XWindowsUtil::getCurrentTime (display=0x56543cb95b10, window=20971524) at /usr/src/debug/synergy-1.7.6-stable/src/lib/platform/XWindowsUtil.cpp:1455
#7  0x000056543c87bbe0 in XWindowsScreen::setClipboard (this=0x56543cb94670, id=<optimized out>, clipboard=0x56543cbb4680)
    at /usr/src/debug/synergy-1.7.6-stable/src/lib/platform/XWindowsScreen.cpp:395
#8  0x000056543c88c91d in Server::sendClipboardThread (this=0x56543cbb45a0) at /usr/src/debug/synergy-1.7.6-stable/src/lib/server/Server.cpp:1866
#9  0x000056543c8c31cf in Thread::threadFunc (vjob=0x56543cc05ac0) at /usr/src/debug/synergy-1.7.6-stable/src/lib/mt/Thread.cpp:157
#10 0x000056543c8640ec in ArchMultithreadPosix::doThreadFunc (this=0x7ffe1c6e1930, thread=0x56543cc02f80)
    at /usr/src/debug/synergy-1.7.6-stable/src/lib/arch/unix/ArchMultithreadPosix.cpp:726
#11 0x000056543c8641db in ArchMultithreadPosix::threadFunc (vrep=0x56543cc02f80) at /usr/src/debug/synergy-1.7.6-stable/src/lib/arch/unix/ArchMultithreadPosix.cpp:707
#12 0x00007f8ffe0b35ca in start_thread (arg=0x7f8ff522a700) at pthread_create.c:333
#13 0x00007f8ffbf2bead in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

What seems to help trigger the the hangs is using the clipboard (copying something from the remote desktop and trying to paste it on the local desktop).

On my setup I have 2 laptops. The main laptop (the one I use the keyboard and trackpad) runs synergys and the secondary laptop runs synergyc. The connection between them is cabled through the home router (no wifi). Both laptops run Fedora 24.

Version-Release number of selected component (if applicable):

How reproducible:
Usually it happens very quickly, a few times trying to copy/paste from remote to local desktop should be enough to trigger it.

Steps to Reproduce:
1. Just try to copy/paste content from the remote desktop to the local desktop a few times.

Actual results:
synergs hangs and has to be killed with kill -9.

Expected results:
No hangs.

Additional info:

Comment 1 Trevor Cordes 2016-09-27 09:11:32 UTC
Same problem here with F23:

Synergy never did this with the newest version that was on F22.  This started with F23 when I upgraded a few weeks ago.

Comment 2 Jonathan Wakely 2016-09-30 11:24:46 UTC
Full backtrace:

(gdb) thread apply all bt

Thread 4 (Thread 0x7ff717967700 (LWP 8503)):
#0  do_sigwait (sig=0x7ff717966d2c, set=<optimized out>) at ../sysdeps/unix/sysv/linux/sigwait.c:64
#1  __sigwait (set=<optimized out>, sig=0x7ff717966d2c) at ../sysdeps/unix/sysv/linux/sigwait.c:96
#2  0x0000563e50766b03 in ArchMultithreadPosix::threadSignalHandler(void*) ()
#3  0x00007ff71e69661a in start_thread (arg=0x7ff717967700) at pthread_create.c:334
#4  0x00007ff71c51c5fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 3 (Thread 0x7ff717166700 (LWP 8504)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x0000563e5076697d in ArchMultithreadPosix::waitCondVar(ArchCondImpl*, ArchMutexImpl*, double) ()
#2  0x0000563e507c8105 in SocketMultiplexer::serviceThread(void*) ()
#3  0x0000563e507cabd3 in Thread::threadFunc(void*) ()
#4  0x0000563e50767a53 in ArchMultithreadPosix::doThreadFunc(ArchThreadImpl*) ()
#5  0x0000563e50767b2b in ArchMultithreadPosix::threadFunc(void*) ()
#6  0x00007ff71e69661a in start_thread (arg=0x7ff717166700) at pthread_create.c:334
#7  0x00007ff71c51c5fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7ff706ffd700 (LWP 5745)):
#0  0x00007ff71c510b7d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ff719987272 in poll (__timeout=-1, __nfds=1, __fds=0x7ff706ffc9a0) at /usr/include/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0x563e51025c00, cond=cond@entry=0x563e51025c40, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:459
#3  0x00007ff719988ee7 in xcb_wait_for_event (c=0x563e51025c00) at xcb_in.c:693
#4  0x00007ff71daece78 in _XReadEvents (dpy=dpy@entry=0x563e51023ed0) at xcb_io.c:401
#5  0x00007ff71dad47f9 in XIfEvent (dpy=0x563e51023ed0, event=0x7ff706ffcbe0, predicate=0x563e507848a0 <XWindowsUtil::propertyNotifyPredicate(_XDisplay*, _XEvent*, char*)>, arg=0x7ff706ffcb40 "\004") at IfEvent.c:68
#6  0x0000563e50784afb in XWindowsUtil::getCurrentTime(_XDisplay*, unsigned long) ()
#7  0x0000563e507873bf in XWindowsClipboard::motifLockClipboard() const ()
#8  0x0000563e50787718 in XWindowsClipboard::open(unsigned int) const ()
#9  0x0000563e507c1dc5 in IClipboard::copy(IClipboard*, IClipboard const*, unsigned int) ()
#10 0x0000563e5079251a in Server::sendClipboardThread(void*) ()
#11 0x0000563e507cabd3 in Thread::threadFunc(void*) ()
#12 0x0000563e50767a53 in ArchMultithreadPosix::doThreadFunc(ArchThreadImpl*) ()
#13 0x0000563e50767b2b in ArchMultithreadPosix::threadFunc(void*) ()
#14 0x00007ff71e69661a in start_thread (arg=0x7ff706ffd700) at pthread_create.c:334
#15 0x00007ff71c51c5fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7ff71ea8c880 (LWP 8502)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ff71daed255 in _XReply (dpy=dpy@entry=0x563e51023ed0, rep=rep@entry=0x7ffc6923c310, extra=extra@entry=0, discard=discard@entry=1) at xcb_io.c:624
#2  0x00007ff71dae8bdd in XSync (dpy=0x563e51023ed0, discard=0) at Sync.c:44
#3  0x0000563e50784dfc in XWindowsUtil::ErrorLock::install(void (*)(_XDisplay*, XErrorEvent*, void*), void*) ()
#4  0x0000563e50784ecc in XWindowsUtil::getWindowProperty(_XDisplay*, unsigned long, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, unsigned long*, int*, bool) ()
#5  0x0000563e50785c5d in XWindowsScreenSaver::isXScreenSaver(unsigned long) const ()
#6  0x0000563e50786c10 in XWindowsScreenSaver::handleXEvent(_XEvent const*) ()
#7  0x0000563e507819a0 in XWindowsScreen::handleSystemEvent(Event const&, void*) ()
#8  0x0000563e5076910a in EventQueue::dispatchEvent(Event const&) ()
#9  0x0000563e5076bbec in EventQueue::loop() ()
#10 0x0000563e5077790a in ServerApp::mainLoop() ()
#11 0x0000563e50773505 in App::daemonMainLoop(int, char const**) ()
#12 0x0000563e507665ba in ArchDaemonUnix::daemonize(char const*, int (*)(int, char const**)) ()
#13 0x0000563e507751de in ServerApp::runInner(int, char**, ILogOutputter*, int (*)(int, char**)) ()
#14 0x0000563e50773d29 in App::run(int, char**) ()
#15 0x0000563e50760c12 in main ()

Comment 3 Jonathan Wakely 2016-09-30 11:28:11 UTC
I'm unable to reproduce this after updating the server side to the synergy-v1.8.3-stable-db9181b-Linux-x86_64.rpm paclage provided by upstream. Updating the client side to 1.8.3 didn't help, I could still make the server hang. After updating both the problem is gone.

Bug 1372714 is tracking the new version.

Comment 4 Fedora End Of Life 2017-07-25 22:39:04 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 5 Fedora End Of Life 2017-08-08 16:48:39 UTC
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.