Hide Forgot
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 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (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): synergy-1.7.6-1.fc24.x86_64 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. 2. 3. Actual results: synergs hangs and has to be killed with kill -9. Expected results: No hangs. Additional info:
Same problem here with F23: synergy-1.7.6-1.fc23.x86_64 Synergy never did this with the newest version that was on F22. This started with F23 when I upgraded a few weeks ago.
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 ()
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.
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.