Have _synergy-v1.7.3-stable-efd0108-Linux-x86_64.deb_ installed on both machines.
Both client and server are running Ubuntu 15.04 with Unity.
Copying on the server and pasting on the client works fine, but copying on the client and pasting on the server doesn't work - when trying to paste on the server, the clipboard on the server appears empty (context menu item "Paste" is disabled).
I thought it might be specific to my client/server = Ubuntu/Ubuntu configuration, but other people experience the same problem with different OSs and mixed setups.
It doesn't work even with plain text, it doesn't work with rich text (some people had similar problems with rich text only)
I have this exact same issue with FC22 (client) and Ubuntu 14.04 (server). Running 1.73 on both
Me too, but Windows 7 (Server) Ubuntu 14.04 Desktop (client). Copy Server to Client work, client to server not.
Trans-IP, zippo-71 - thank you.
Sounds like this issue is not Ubuntu/Ubuntu specific - I will update the title accordingly.
I too have this issue. I've noticed that it usually is copying from "advanced" programs. Going from Client => Server, it tends to work if I copy from say (for example) Outlook (client) => Notepad (client) => Excel (server) it works. FWIW, I have Win 7 server, Win 8.1 Client.
In my case it doesn't work no matter what program I'm copying from on the client - I tried copying from terminal, text editors (gedit, atom), IDEs, LibreOffice.
Same issue here with Server:Win7(non-elevated) / Client:Win7(elevated) setup. Can copy on server and paste to client but cannot copy on client and paste to server.
I don't have a keyboard attached to the Win7 client so I can't test dropping the elevation on the client.
For me Copy/paste was working reliably untill version 1.7.2. With 1.7.3 it works 10% of time @ random
OS: Gentoo Linux on clients and server
The two most common causes of clipboard issues currently are:
If either of these describe your situation, then your issue probably a duplicate of at least some of these (the "main" threads are highlighted in bold):
(Basically just search the Issues for "clipboard".) Don't ask me what the pattern is for still open vs closed vs duplicate or not.
Well - in my case it's almost always plain text. And it's something like this:
And it's just last ~8h of work. There are also non-copying issues, like using 100% of core on any client, server dying for no apparent reason during swithc screen (clipboard empty at times). And up until 1.7.2 synergy was working fine for me for most of the content and I don't really care about rich content.
For me it's always plain text aswell, but I assume it's tied to the Elevate setting.
The clipboard problems might be related to the recent change in the clipboard protocol: 257c19ecc4c2a23f034b3b976058b6353604c27a
I can confirm this.
I can go from Server --> client without problem, but going from client --> server fails every time. Doesn't matter which version of Linux is the server.
There seems to be some sort of 1024-ish limit in the new protocol. Doing some testing from my Redhat 22 server to my Windows 7 client, both running 1.7.3, I found that I'd get debug notifications on Windows about clipboard changed up through 1012 characters, but if my original copy buffer was larger than that, I'd get no clipboard update on Windows at all. Here's the log of the largest payload that came over OK:
INFO: entering screen
DEBUG: start receiving clipboard data
DEBUG: received clipboard 0 size=1024
DEBUG: open clipboard
DEBUG: empty clipboard
DEBUG: add 1012 bytes to clipboard format: 0
DEBUG: close clipboard
INFO: leaving screen
@unwiredben That's a separate issue related to the new SSL plugin, and is documented here:
If you are using SSL, please check #4712
There is a nightly ready for test.
Basic copy and pasting from client to server fails with this DEBUG2 server output:
DEBUG2: read property 313 on window 0x0380009d: bytes=4
DEBUG2: _NET_WM_PID (CARDINAL): 06 09 00 00
DEBUG2: read property 300 on window 0x0380009d: bytes=11
DEBUG2: WM_LOCALE_NAME (STRING): en_US.UTF-8
DEBUG2: read property 36 on window 0x0380009d: bytes=26
DEBUG2: WM_CLIENT_MACHINE (STRING): gare-Precision-T3610-Linux
DEBUG2: read property 40 on window 0x0380009d: bytes=72
DEBUG2: WM_NORMAL_HINTS (WM_SIZE_HINTS): 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
DEBUG2: read property 301 on window 0x0380009d: bytes=16
DEBUG2: WM_PROTOCOLS (ATOM): 0b 01 00 00 00 00 00 00 0e 01 00 00 00 00 00 00
DEBUG2: read property 37 on window 0x0380009d: bytes=5
DEBUG2: WM_ICON_NAME (STRING): gedit
DEBUG2: read property 311 on window 0x0380009d: bytes=5
DEBUG2: _NET_WM_ICON_NAME (UTF8_STRING): gedit
DEBUG2: read property 39 on window 0x0380009d: bytes=5
DEBUG2: WM_NAME (STRING): gedit
DEBUG2: read property 312 on window 0x0380009d: bytes=5
DEBUG2: _NET_WM_NAME (UTF8_STRING): gedit
DEBUG2: can't read property 457 on window 0x0380009d
DEBUG1: received property GDK_SELECTION (341) delete from 0x08380009d
DEBUG1: clipboard: finished reply to 0x0380009d,448,341
DEBUG1: request for clipboard 465, target UTF8_STRING (297) by 0x0380009d (property=GDK_SELECTION (341))
DEBUG1: failed
DEBUG1: clipboard: sending failure to 0x0380009d,297,0
DEBUG1: request for clipboard 465, target COMPOUND_TEXT (523) by 0x0380009d (property=GDK_SELECTION (341))
DEBUG1: failed
DEBUG1: clipboard: sending failure to 0x0380009d,523,0
DEBUG1: request for clipboard 465, target STRING (31) by 0x0380009d (property=GDK_SELECTION (341))
DEBUG1: failed
DEBUG1: clipboard: sending failure to 0x0380009d,31,0
DEBUG2: event: MotionNotify 937,287
Same:
Copy/Paste Client (Linux Mint 16) -> Server (OSX 10.10.3) does not work.
Other way around work.
I have the same issue.
Synergy on Linux freezes with data from win.
@nmodin @webdawg
Please test this nightly.
Same issue for me with Linux client and Windows Server on the latest nightly. Works fine from Windows -> Linux, maybe 1 in 10 work from Linux -> Windows
@symonds
Nightly 121080?
Which Linux are you using? Any log information?
I tried nightly 121080.
Server is crashing whenever client tries to connect.
Both client and server are Ubuntu 15.04 x64
Can somebody point me to where the log files are? I can't find them. The only thing I see in /var/log/syslog is:
Jun 23 10:34:27 synergy[22612]: *** WARNING *** The program 'synergy' uses the Apple Bonjour compatibility layer of Avahi.
Jun 23 10:34:27 synergy[22612]: *** WARNING *** Please fix your application to use the native API of Avahi!
Jun 23 10:34:27 synergy[22612]: *** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=synergy>
Jun 23 10:34:28 kernel: [124114.611536] synergyc[22629]: segfault at 7f64b9f000c0 ip 00007f64bdf426e9 sp 00007ffce0d14af0 error 7 in libpthread-2.21.so[7f64bdf39000+18000]
@XinyuHou
Yes using that nightly. Win7 Host (1), Arch x86_64 Client (2).
Copy from Client to Host
INFO: switch from "1" to "2" at 0,599
INFO: leaving screen
INFO: switch from "2" to "1" at 1918,571
INFO: entering screen
INFO: switch from "1" to "2" at 0,579
INFO: leaving screen
INFO: screen "2" grabbed clipboard 1 from "1"
INFO: screen "2" grabbed clipboard 0 from "1"
INFO: switch from "2" to "1" at 1918,288
INFO: entering screen
NOTE: Clipboard Transmission Started: Start receiving 4 bytes of clipboard data.
NOTE: Clipboard Transmission Complete: Clipboard is updated.
NOTE: Clipboard Transmission Started: Start receiving 4 bytes of clipboard data.
NOTE: Clipboard Transmission Complete: Clipboard is updated.
However this is not the correct number of bytes, and paste is not an option. It also doesn't sync for at least 10 seconds after changing active screen and seems to be syncing in the wrong direction? (at least that what the logs suggest...)
@panamik
In Edit->Settings you can specify log file path.
@symonds
Is log from server side?
NOTE: Clipboard Transmission Started: Start receiving 4 bytes of clipboard data.
This seems a bug. Could you please create a new issue?
It also doesn't sync for at least 10 seconds after changing active screen
Did you mean you can see Clipboard Transmission log 10 sec after change screen?
@XinyuHou
Yep Server side logs.
Maybe 10 seconds is a exaggeration. More like 3-5 seconds after switching screen back to the server.
Thanks XinyuHou for helping me find the logs.
I tried latest nightly http://synergy-project.org/nightly?filter=3aebb87 with Debug2 log level.
The sequence is:
I don't see anything interesting in the logs, but here they are synergy-client.log and synergy-server.log, maybe you will notice something.
Both server and client are Ubuntu 15.04 with Unity.
PS: I had the same problem with nightly 121080.
I'm having a smiler issue, using a RHEL6 Server and RHEL7 Client. On the RHEL7 client the clipboard doesn't work at all while using the servers mouse and keyboard, but works fine when using the mouse and keyboard that's plugged directly into it.
I am testing http://synergy-project.org/nightly?filter=121080 right now on archlinux x64
Crashed on copy from a windows system.
Please tell me what parameters that you want for DEBUG and I will run output to the log file.
One more thing, I only ran this test on the server (Archlinux x64) because it is what seems to freeze. Should I update client also?
FYI, http://synergy-project.org/nightly?filter=3aebb8 seems to have fixed this for me with Mac server and Linux client.
@panamik
If you use SSL, you need to rerun the wizard.
@webdawg
Please use DEBUG2 level and update on both server and client.
I appear to be experiencing the same clipboard issue. The client application crashes when copying over to the server. The crash happens the moment you move your mouse back to the server from the client, after copying a substantial amount of data into the clipboard. I have been testing in a 'hot-cold game' fashion to try to narrow down the exact size that causes the crash. It looks to be roughly 1520 characters. less then 1500 characters I never get the crash. More then 1540, I get the crash every time. When I get right in up the 1515-1530 range, it's inconsistent. Sometimes it works, sometimes it does not. My guess is that this inconsistency is caused by other meta-data that might be being sent along with the clipboard transmission to the server.
I believe the reason it usually does not work when pasting from a complete application like Excel or MS-Word, is that these applications will be sending a lot of other formatting information along with it, making it quickly consume more then 1520 bytes.
Server: win7
Client: win 8.1
Synergy Version: 1.7.3
SSL: Enabled <----- * Edit: Disabling this stops the crash described above *
I used Notepad++ during my copy/paste tests
@ColinCreamer
Which version of Synergy are you using? With SSL or non-SSL?
@XinyuHou Updated my comment.
@ColinCreamer
Please try out latest nightly for 1.7.4
http://synergy-project.org/nightly?filter=3aebb8
NOTO: rerun wizard to get latest plugins.
Disabling SSL greatly improved the max transmission size before a crash from 1500 to over 600,000. It still crashes if I go over 700,000 characters though.
(Still old version)
Edit:June30 Installed nightly 1.7.4 on client. 1500 character limit remains with SSL. 600,000 limit lifted without SSL.
SSL is disabled. I am on 673fba5 on both server and client, and copying from linux (client) to windows (server) does not work with basic highlight in a terminal, you have to do explicit "copy". Used to be not necessary.
Just tried the nightly, using ssl, copy and paste is still broken on client computer. One other note, I can copy from the server to the client but other then that copy and paste does not work on the client unless I'm using the keyboard directly plugged into it.
@XinyuHou
Have Installed your linked nightly 1.7.4 build on the client machine. The 1500 character max remains when SSL is enabled however, the 600,000 character max when SSL is disabled has been lifted. Can now copy over 4 million characters without crash while SSL is disabled.
Edit: No change after installing 1.7.4 on server machine also.
@ColinCreamer @ccgurley @nyetwurk
Please use the nightly on both server and client sides and rerun wizard to get latest plugin.
If the issue still persists, please change log level to Debug2 and send us your log along with your platforms information.
Problem appears to be client side (linux)
DEBUG: open clipboard 1
DEBUG1: request selection=PRIMARY (1), target=TIMESTAMP (366), window=1c00004
DEBUG2: can't read property 502 on window 0x01c00004
DEBUG1: request failed
DEBUG1: can't get data for selection target TIMESTAMP (366)
DEBUG1: can't get ICCCM time
DEBUG: ICCCM fill clipboard 1
DEBUG1: request selection=PRIMARY (1), target=TARGETS (365), window=1c00004
DEBUG2: can't read property 502 on window 0x01c00004
DEBUG2: msg from server: CALV
DEBUG2: writef(CALV)
DEBUG2: wrote 4 bytes
DEBUG2: writef(CNOP)
DEBUG2: wrote 4 bytes
DEBUG1: request failed
DEBUG1: can't get data for selection target TARGETS (365)
DEBUG1: selection doesn't support TARGETS
DEBUG: available targets: STRING (31)
DEBUG1: request selection=PRIMARY (1), target=text/html (509), window=1c00004
DEBUG1: request failed
DEBUG1: can't get data for selection target text/html (509)
DEBUG1: no data for target text/html (509)
DEBUG1: request selection=PRIMARY (1), target=image/bmp (510), window=1c00004
DEBUG1: request failed
DEBUG1: can't get data for selection target image/bmp (510)
DEBUG1: no data for target image/bmp (510)
DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=UTF-8 (511), window=1c00004
DEBUG1: request failed
DEBUG1: can't get data for selection target text/plain;charset=UTF-8 (511)
DEBUG1: no data for target text/plain;charset=UTF-8 (511)
DEBUG1: request selection=PRIMARY (1), target=UTF8_STRING (284), window=1c00004
DEBUG2: can't read property 502 on window 0x01c00004
DEBUG1: request failed
DEBUG1: can't get data for selection target UTF8_STRING (284)
DEBUG1: no data for target UTF8_STRING (284)
DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=ISO-10646-UCS-2 (512), window=1c00004
DEBUG1: request failed
DEBUG1: can't get data for selection target text/plain;charset=ISO-10646-UCS-2 (512)
DEBUG1: no data for target text/plain;charset=ISO-10646-UCS-2 (512)
DEBUG1: request selection=PRIMARY (1), target=text/unicode (513), window=1c00004
DEBUG1: request failed
DEBUG1: can't get data for selection target text/unicode (513)
DEBUG1: no data for target text/unicode (513)
DEBUG1: request selection=PRIMARY (1), target=text/plain (514), window=1c00004
DEBUG2: can't read property 502 on window 0x01c00004
DEBUG1: request failed
DEBUG1: can't get data for selection target text/plain (514)
DEBUG1: no data for target text/plain (514)
DEBUG1: request selection=PRIMARY (1), target=STRING (31), window=1c00004
DEBUG2: can't read property 502 on window 0x01c00004
DEBUG1: request failed
DEBUG1: can't get data for selection target STRING (31)
DEBUG1: no data for target STRING (31)
DEBUG: close clipboard 1
@nyetwurk
you have to do explicit "copy".
What do you mean?
There are two clipboards on X systems.
X NEVER had a "copy" back in the day. Just highlighting text in a terminal automatically put it in the cilpboard for pasting.
When windows added explicit copy/paste (copying MacOS), they added a second clipboard to X for explicit copies.
Not necessarily relevant to the problem, but relevant to nyetwork's comment above, Jamie Zawinski (creator of, among other things, xscreensaver) had this to say about selections and copy paste in X:
http://www.jwz.org/doc/x-cut-and-paste.html
I have a similar problem. Copy + Paste works both ways on boot of both machines, but after awhile fails and never works again. The only solution is to restart Synergy on both machines (which requires a reboot of the machine without a keyboard). My setup is a fully up to date Windows 8 server and OS X client.
BTW explicit copy isn't working for me anymore either, since I moved to the master branch.
It seems as though the problem is that the clipboard contents are requested once the mouse has _left_ the client screen, and that is too late - the copy works as long as the mouse is still on the client screen.
working "copy" (done with client mouse, not server mouse)
[2015-07-07T12:18:22] DEBUG: open clipboard 1
[2015-07-07T12:18:22] DEBUG1: request selection=PRIMARY (1), target=TIMESTAMP (366), window=1e00004
[2015-07-07T12:18:22] DEBUG1: target INTEGER (19)
[2015-07-07T12:18:22] DEBUG1: got data, 4 bytes
[2015-07-07T12:18:22] DEBUG1: request succeeded after 0.000000s
[2015-07-07T12:18:22] DEBUG1: got ICCCM time 907879100
[2015-07-07T12:18:22] DEBUG: ICCCM fill clipboard 1
[2015-07-07T12:18:22] DEBUG1: request selection=PRIMARY (1), target=TARGETS (365), window=1e00004
[2015-07-07T12:18:22] DEBUG1: target ATOM (4)
[2015-07-07T12:18:22] DEBUG1: got data, 36 bytes
[2015-07-07T12:18:22] DEBUG1: request succeeded after 0.000004s
[2015-07-07T12:18:22] DEBUG: available targets: TIMESTAMP (366), TARGETS (365), MULTIPLE (362), UTF8_STRING (284), COMPOUND_TEXT (462)
[2015-07-07T12:18:22] DEBUG1: request selection=PRIMARY (1), target=text/html (509), window=1e00004
[2015-07-07T12:18:22] DEBUG1: request succeeded after 0.000002s
[2015-07-07T12:18:22] DEBUG1: selection conversion failed for target text/html (509)
[2015-07-07T12:18:22] DEBUG1: no data for target text/html (509)
[2015-07-07T12:18:22] DEBUG1: request selection=PRIMARY (1), target=image/bmp (510), window=1e00004
[2015-07-07T12:18:22] DEBUG1: request succeeded after 0.000000s
[2015-07-07T12:18:22] DEBUG1: selection conversion failed for target image/bmp (510)
[2015-07-07T12:18:22] DEBUG1: no data for target image/bmp (510)
[2015-07-07T12:18:22] DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=UTF-8 (511), window=1e00004
[2015-07-07T12:18:22] DEBUG1: request succeeded after 0.000000s
[2015-07-07T12:18:22] DEBUG1: selection conversion failed for target text/plain;charset=UTF-8 (511)
[2015-07-07T12:18:22] DEBUG1: no data for target text/plain;charset=UTF-8 (511)
[2015-07-07T12:18:22] DEBUG1: request selection=PRIMARY (1), target=UTF8_STRING (284), window=1e00004
[2015-07-07T12:18:22] DEBUG1: target UTF8_STRING (284)
[2015-07-07T12:18:22] DEBUG1: got data, 271 bytes
[2015-07-07T12:18:22] DEBUG1: request succeeded after 0.000002s
[2015-07-07T12:18:22] DEBUG: added format 0 for target UTF8_STRING (284) (271 bytes)
[2015-07-07T12:18:22] DEBUG: close clipboard 1
[2015-07-07T12:18:22] DEBUG: sending clipboard 1 seqnum=0
[2015-07-07T12:18:22] DEBUG: sent clipboard size=283
Broken (done with server mouse after it exits the client)
[2015-07-07T12:19:21] INFO: leaving screen
[2015-07-07T12:19:21] DEBUG1: thread 0x00000003 entry
[2015-07-07T12:19:21] DEBUG: open clipboard 1
[2015-07-07T12:19:21] DEBUG1: request selection=PRIMARY (1), target=TIMESTAMP (366), window=1e00004
[2015-07-07T12:19:21] DEBUG1: request failed after 0.252042s
[2015-07-07T12:19:21] DEBUG1: can't get data for selection target TIMESTAMP (366)
[2015-07-07T12:19:21] DEBUG1: can't get ICCCM time
[2015-07-07T12:19:21] DEBUG: ICCCM fill clipboard 1
[2015-07-07T12:19:21] DEBUG1: request selection=PRIMARY (1), target=TARGETS (365), window=1e00004
[2015-07-07T12:19:21] DEBUG1: request failed after 0.252029s
[2015-07-07T12:19:21] DEBUG1: can't get data for selection target TARGETS (365)
[2015-07-07T12:19:21] DEBUG1: selection doesn't support TARGETS
[2015-07-07T12:19:21] DEBUG: available targets: STRING (31)
[2015-07-07T12:19:21] DEBUG1: request selection=PRIMARY (1), target=text/html (509), window=1e00004
[2015-07-07T12:19:21] DEBUG1: request failed after 0.252265s
[2015-07-07T12:19:21] DEBUG1: can't get data for selection target text/html (509)
[2015-07-07T12:19:21] DEBUG1: no data for target text/html (509)
[2015-07-07T12:19:21] DEBUG1: request selection=PRIMARY (1), target=image/bmp (510), window=1e00004
[2015-07-07T12:19:22] DEBUG1: request failed after 0.252108s
[2015-07-07T12:19:22] DEBUG1: can't get data for selection target image/bmp (510)
[2015-07-07T12:19:22] DEBUG1: no data for target image/bmp (510)
[2015-07-07T12:19:22] DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=UTF-8 (511), window=1e00004
[2015-07-07T12:19:22] DEBUG1: request failed after 0.251989s
[2015-07-07T12:19:22] DEBUG1: can't get data for selection target text/plain;charset=UTF-8 (511)
[2015-07-07T12:19:22] DEBUG1: no data for target text/plain;charset=UTF-8 (511)
[2015-07-07T12:19:22] DEBUG1: request selection=PRIMARY (1), target=UTF8_STRING (284), window=1e00004
[2015-07-07T12:19:22] DEBUG1: request failed after 0.252061s
[2015-07-07T12:19:22] DEBUG1: can't get data for selection target UTF8_STRING (284)
[2015-07-07T12:19:22] DEBUG1: no data for target UTF8_STRING (284)
[2015-07-07T12:19:22] DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=ISO-10646-UCS-2 (512), window=1e00004
[2015-07-07T12:19:22] DEBUG1: request failed after 0.252247s
[2015-07-07T12:19:22] DEBUG1: can't get data for selection target text/plain;charset=ISO-10646-UCS-2 (512)
[2015-07-07T12:19:22] DEBUG1: no data for target text/plain;charset=ISO-10646-UCS-2 (512)
[2015-07-07T12:19:22] DEBUG1: request selection=PRIMARY (1), target=text/unicode (513), window=1e00004
[2015-07-07T12:19:23] DEBUG1: request failed after 0.252260s
[2015-07-07T12:19:23] DEBUG1: can't get data for selection target text/unicode (513)
[2015-07-07T12:19:23] DEBUG1: no data for target text/unicode (513)
[2015-07-07T12:19:23] DEBUG1: request selection=PRIMARY (1), target=text/plain (514), window=1e00004
[2015-07-07T12:19:23] DEBUG1: request failed after 0.252037s
[2015-07-07T12:19:23] DEBUG1: can't get data for selection target text/plain (514)
[2015-07-07T12:19:23] DEBUG1: no data for target text/plain (514)
[2015-07-07T12:19:23] DEBUG1: request selection=PRIMARY (1), target=STRING (31), window=1e00004
[2015-07-07T12:19:23] DEBUG1: request failed after 0.252098s
[2015-07-07T12:19:23] DEBUG1: can't get data for selection target STRING (31)
[2015-07-07T12:19:23] DEBUG1: no data for target STRING (31)
[2015-07-07T12:19:23] DEBUG: close clipboard 1
Notice the ridiculous timeouts as well: EACH converter times out in turn, because the converter search method is also somewhat broken; if the TARGETS get fails, the code adds "STRING", but then the converter search ignores that there is only "STRING" due to this:
Atom target = None;
// XXX -- just ask for the converter's target to see if it's
// available rather than checking TARGETS. i've seen clipboard
// owners that don't report all the targets they support.
target = converter->getAtom();
And instead of looking through the target list (which only contains string), it goes through every converter, each of which fails by TIMEOUT!
This issue is for Linux server and Linux client.
my --version says 1.7.4
no ssl
Windows server, Linux client.
I don't have clipboard usage at all and I have times every 15-30 minutes where the client will stop working and I use ssh to restart it. It won't crash so I can't use systemd to restart it like I normally would so this bug turns out to be pretty annoying.
In the log it says server is dead. But the server is never dead and restarting the client and leaving the server alone fixes the drop every time.
[2015-07-22T15:55:27] DEBUG2: readf: read 2 byte integer: 3 (0x3)
[2015-07-22T15:55:27] DEBUG2: readf: read 2 byte integer: 79 (0x4f)
[2015-07-22T15:55:27] DEBUG2: recv mouse move 3,79
[2015-07-22T15:55:27] DEBUG2: writef(CNOP)
[2015-07-22T15:55:27] DEBUG2: wrote 4 bytes
[2015-07-22T15:55:27] DEBUG2: msg from server: DMMV
[2015-07-22T15:55:27] DEBUG2: readf(%2i%2i)
[2015-07-22T15:55:27] DEBUG2: readf: read 2 byte integer: 0 (0x0)
[2015-07-22T15:55:27] DEBUG2: readf: read 2 byte integer: 78 (0x4e)
[2015-07-22T15:55:27] DEBUG2: recv mouse move 0,78
[2015-07-22T15:55:27] DEBUG2: writef(CNOP)
[2015-07-22T15:55:27] DEBUG2: wrote 4 bytes
[2015-07-22T15:55:27] DEBUG2: msg from server: COUT
[2015-07-22T15:55:27] DEBUG1: recv leave
[2015-07-22T15:55:27] INFO: leaving screen
[2015-07-22T15:55:27] DEBUG2: mapping state: 0
[2015-07-22T15:55:27] DEBUG2: writef(CNOP)
[2015-07-22T15:55:27] DEBUG1: thread 0x00000010 entry
[2015-07-22T15:55:27] DEBUG2: wrote 4 bytes
[2015-07-22T15:55:27] DEBUG: open clipboard 1
[2015-07-22T15:55:27] DEBUG1: request selection=PRIMARY (1), target=TIMESTAMP (347), window=6600004
[2015-07-22T15:55:27] DEBUG2: can't read property 440 on window 0x06600004
[2015-07-22T15:55:27] DEBUG2: can't read property 440 on window 0x06600004
[2015-07-22T15:55:27] DEBUG1: request failed
[2015-07-22T15:55:27] DEBUG1: can't get data for selection target TIMESTAMP (347)
[2015-07-22T15:55:27] DEBUG1: can't get ICCCM time
[2015-07-22T15:55:27] DEBUG: ICCCM fill clipboard 1
[2015-07-22T15:55:27] DEBUG1: request selection=PRIMARY (1), target=TARGETS (346), window=6600004
[2015-07-22T15:55:27] DEBUG2: can't read property 440 on window 0x06600004
[2015-07-22T15:55:28] DEBUG1: request failed
[2015-07-22T15:55:28] DEBUG1: can't get data for selection target TARGETS (346)
[2015-07-22T15:55:28] DEBUG1: selection doesn't support TARGETS
[2015-07-22T15:55:28] DEBUG: available targets: STRING (31)
[2015-07-22T15:55:28] DEBUG1: request selection=PRIMARY (1), target=text/html (447), window=6600004
[2015-07-22T15:55:28] DEBUG1: request failed
[2015-07-22T15:55:28] DEBUG1: can't get data for selection target text/html (447)
[2015-07-22T15:55:28] DEBUG1: no data for target text/html (447)
[2015-07-22T15:55:28] DEBUG1: request selection=PRIMARY (1), target=image/bmp (448), window=6600004
[2015-07-22T15:55:28] DEBUG2: msg from server: CALV
[2015-07-22T15:55:28] DEBUG2: writef(CALV)
[2015-07-22T15:55:28] DEBUG2: wrote 4 bytes
[2015-07-22T15:55:28] DEBUG2: writef(CNOP)
[2015-07-22T15:55:28] DEBUG2: wrote 4 bytes
[2015-07-22T15:55:28] DEBUG1: request failed
[2015-07-22T15:55:28] DEBUG1: can't get data for selection target image/bmp (448)
[2015-07-22T15:55:28] DEBUG1: no data for target image/bmp (448)
[2015-07-22T15:55:28] DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=UTF-8 (449), window=6600004
[2015-07-22T15:55:28] DEBUG2: can't read property 440 on window 0x06600004
[2015-07-22T15:55:28] DEBUG1: request failed
[2015-07-22T15:55:28] DEBUG1: can't get data for selection target text/plain;charset=UTF-8 (449)
[2015-07-22T15:55:28] DEBUG1: no data for target text/plain;charset=UTF-8 (449)
[2015-07-22T15:55:28] DEBUG1: request selection=PRIMARY (1), target=UTF8_STRING (256), window=6600004
[2015-07-22T15:55:37] INFO: server is dead
Hi,
yesterday I've upgraded to 1.7.3 and I'm having issues with clipboard/crashing.
See logs below
SERVER: win-srv (windows 7, synergy 1.7.3 64bit, downloaded from synergy)
CLIENT: lin-cli (ArchLinux, synergy 1.7.3-2 64bit, official package)
### SERVER LOG ###
synergys.exe -f --name win-srv --stop-on-desk-switch --enable-drag-drop -c synergy.conf --address :12340
INFO: drag and drop enabled
NOTE: started server, waiting for clients
NOTE: accepted client connection
NOTE: client "lin-cli" has connected
INFO: screen "win-srv" grabbed clipboard 0 from "win-srv"
INFO: screen "win-srv" grabbed clipboard 1 from "win-srv"
INFO: switch from "win-srv" to "lin-cli" at 0,330
INFO: leaving screen
INFO: screen "win-srv" updated clipboard 0
INFO: screen "win-srv" updated clipboard 1
INFO: screen "lin-cli" grabbed clipboard 1 from "win-srv"
INFO: screen "lin-cli" grabbed clipboard 0 from "win-srv"
INFO: switch from "lin-cli" to "win-srv" at 1652,271
INFO: entering screen
INFO: switch from "win-srv" to "lin-cli" at 0,388
INFO: leaving screen
INFO: switch from "lin-cli" to "win-srv" at 1652,240
INFO: entering screen
INFO: screen "win-srv" grabbed clipboard 0 from "lin-cli"
INFO: screen "win-srv" grabbed clipboard 1 from "lin-cli"
NOTE: client "lin-cli" has disconnected
NOTE: accepted client connection
NOTE: client "lin-cli" has connected
### CLIENT LOG ###
# Linux lin-cli 4.1.2-2-ARCH 1 SMP PREEMPT Wed Jul 15 08:30:32 UTC 2015 x86_64 GNU/Linux
/usr/bin/synergyc -f --debug INFO --name lin-cli win-srv:12340
2015-07-23T10:25:42 NOTE: started client
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/ClientApp.cpp,404
2015-07-23T10:25:42 NOTE: connecting to 'win-srv': 192.168.0.84:12340
/build/synergy/src/synergy-1.7.3-stable/src/lib/client/Client.cpp,160
2015-07-23T10:25:42 NOTE: connected to server
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/ClientApp.cpp,294
2015-07-23T10:25:51 INFO: entering screen
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/Screen.cpp,113
2015-07-23T10:26:04 INFO: leaving screen
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/Screen.cpp,131
2015-07-23T10:26:11 INFO: entering screen
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/Screen.cpp,113
2015-07-23T10:26:17 INFO: leaving screen
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/Screen.cpp,131
synergyc: /build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp:317: virtual bool XWindowsClipboard::open(IClipboard::Time) const: Assertion `!m_open' failed.
/home/krtek/bin/mysynergy: line 4: 29076 Aborted (core dumped) /usr/bin/synergyc -f --debug INFO --name lin-cli win-srv:12340
2015-07-23T10:26:27 NOTE: started client
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/ClientApp.cpp,404
2015-07-23T10:26:27 NOTE: connecting to 'win-srv': 192.168.0.84:12340
/build/synergy/src/synergy-1.7.3-stable/src/lib/client/Client.cpp,160
2015-07-23T10:26:27 NOTE: connected to server
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/ClientApp.cpp,294
On 7/9/2015 12:40 PM, Jerry (Xinyu Hou) wrote:
This issue is for Linux server and Linux client.
The problem is for any server (as documented extensively in the bug). The problem is in the linux client, irrespective of server.
@thiemel @nyetwurk @ColinCreamer @jtexp @ccgurley @webdawg @nmodin @garec
Please test this nightly 9b3602
http://synergy-project.org/nightly?filter=9b3602
If you use SSL and have trouble with downloading plugins
Plugin directory:
Windows: %User directory%\AppData\Local\Synergy\Plugins
Mac: ~/Library/Synergy/Plugins
Linux: ~/.synergy/plugins
Please only leave comment that is related to this clipboard issue. Thank you.
I am building from the master branch.
@nyetwurk
We are working on 1.7.4 branch, master is left for 1.8
Same issue, but I am at 1.7.4 branch HEAD - dbd65f6f54ca77195ad49aad7ab20d0196a79367
@nyetwurk
Please try to use relative mouse moves to see if that could help.
On server side click Configure Server
Click Advanced server settings
Tick use relative mouse moves
Click Ok
Click Apply
Same behavior as in https://github.com/synergy/synergy/issues/4735#issuecomment-119308820
@XinyuHou
No change in behavior with that nightly.
[2015-07-23T16:08:07] DEBUG2: readf: read 2 byte integer: 390 (0x186)
[2015-07-23T16:08:07] DEBUG2: recv mouse move 3,390
[2015-07-23T16:08:07] DEBUG2: writef(CNOP)
[2015-07-23T16:08:07] DEBUG2: wrote 4 bytes
[2015-07-23T16:08:07] DEBUG2: msg from server: COUT
[2015-07-23T16:08:07] DEBUG1: recv leave
[2015-07-23T16:08:07] INFO: leaving screen
[2015-07-23T16:08:07] DEBUG2: mapping state: 0
[2015-07-23T16:08:07] DEBUG2: writef(CNOP)
[2015-07-23T16:08:07] DEBUG2: wrote 4 bytes
[2015-07-23T16:08:07] DEBUG1: thread 0x0000000c entry
[2015-07-23T16:08:07] DEBUG2: can't read property 440 on window 0x01400004
[2015-07-23T16:08:07] DEBUG: open clipboard 1
[2015-07-23T16:08:07] DEBUG1: request selection=PRIMARY (1), target=TIMESTAMP (347), window=1400004
[2015-07-23T16:08:07] DEBUG1: request succeeded
[2015-07-23T16:08:07] DEBUG1: selection conversion failed for target TIMESTAMP (347)
[2015-07-23T16:08:07] DEBUG1: can't get ICCCM time
[2015-07-23T16:08:07] DEBUG: ICCCM fill clipboard 1
[2015-07-23T16:08:07] DEBUG1: request selection=PRIMARY (1), target=TARGETS (346), window=1400004
[2015-07-23T16:08:07] DEBUG1: request failed
[2015-07-23T16:08:07] DEBUG1: can't get data for selection target TARGETS (346)
[2015-07-23T16:08:07] DEBUG1: selection doesn't support TARGETS
[2015-07-23T16:08:07] DEBUG2: can't read property 440 on window 0x01400004
[2015-07-23T16:08:07] DEBUG: available targets: STRING (31)
[2015-07-23T16:08:07] DEBUG1: request selection=PRIMARY (1), target=text/html (447), window=1400004
[2015-07-23T16:08:07] DEBUG1: request succeeded
[2015-07-23T16:08:07] DEBUG1: selection conversion failed for target text/html (447)
[2015-07-23T16:08:07] DEBUG1: no data for target text/html (447)
[2015-07-23T16:08:07] DEBUG1: request selection=PRIMARY (1), target=image/bmp (448), window=1400004
[2015-07-23T16:08:07] DEBUG1: request succeeded
[2015-07-23T16:08:07] DEBUG1: selection conversion failed for target image/bmp (448)
[2015-07-23T16:08:07] DEBUG1: no data for target image/bmp (448)
[2015-07-23T16:08:07] DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=UTF-8 (449), window=1400004
[2015-07-23T16:08:07] DEBUG1: request succeeded
[2015-07-23T16:08:07] DEBUG1: selection conversion failed for target text/plain;charset=UTF-8 (449)
[2015-07-23T16:08:07] DEBUG1: no data for target text/plain;charset=UTF-8 (449)
[2015-07-23T16:08:07] DEBUG1: request selection=PRIMARY (1), target=UTF8_STRING (256), window=1400004
[2015-07-23T16:08:07] DEBUG1: request succeeded
[2015-07-23T16:08:07] DEBUG1: selection conversion failed for target UTF8_STRING (256)
[2015-07-23T16:08:07] DEBUG1: no data for target UTF8_STRING (256)
[2015-07-23T16:08:07] DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=ISO-10646-UCS-2 (450), window=1400004
[2015-07-23T16:08:07] DEBUG1: request succeeded
[2015-07-23T16:08:07] DEBUG1: selection conversion failed for target text/plain;charset=ISO-10646-UCS-2 (450)
[2015-07-23T16:08:07] DEBUG1: no data for target text/plain;charset=ISO-10646-UCS-2 (450)
[2015-07-23T16:08:07] DEBUG1: request selection=PRIMARY (1), target=text/unicode (451), window=1400004
[2015-07-23T16:08:07] DEBUG1: request succeeded
After that I can't go back into the linux client. I believe this is the same issue as the clipboard issue, if it's a different issue please link.
@nyetwurk
Do you use SSL? Sorry if you have answered this before.
I just tried nightly 9b3602, the select copy works. Maybe it is related to the program you copy from?
@jtexp
Do you mean you experience connection drop issue rather than select copy issue?
@XinyuHou
no, not using SSL.
Explicit copy sometimes works (but only when running under gdb now). Simple highlight copy never works.
Copying from a gnome-terminal, xterm, etc.
Found interesting behavior: if I do a 2nd copy quickly before the clipboard thread exits, I can get explicit copy to work.
That is to say:
1) copy (either method)
2) exit client screen
3) quickly re-enter client screen
4) quickly explicit copy before clipboard thread exits
5) quickly enter server screen before thread exits
Then it works
Added log of "successful" copy (notice the ATOM message, that is different)
[2015-07-23T14:50:24] INFO: leaving screen
[2015-07-23T14:50:24] DEBUG1: target ATOM (4)
[2015-07-23T14:50:24] DEBUG1: got data, 36 bytes
[2015-07-23T14:50:24] DEBUG1: request succeeded after 0.000001s
[2015-07-23T14:50:24] DEBUG: available targets: TIMESTAMP (366), TARGETS (365), MULTIPLE (362), UTF8_STRING (284), COMPOUND_TEXT (462)
[2015-07-23T14:50:24] DEBUG1: request selection=PRIMARY (1), target=text/html (509), window=1e00004
[2015-07-23T14:50:24] DEBUG1: request succeeded after 0.000001s
[2015-07-23T14:50:24] DEBUG1: selection conversion failed for target text/html (509)
[2015-07-23T14:50:24] DEBUG1: no data for target text/html (509)
[2015-07-23T14:50:24] DEBUG1: request selection=PRIMARY (1), target=image/bmp (510), window=1e00004
[2015-07-23T14:50:24] DEBUG1: request succeeded after 0.000002s
[2015-07-23T14:50:24] DEBUG1: selection conversion failed for target image/bmp (510)
[2015-07-23T14:50:24] DEBUG1: no data for target image/bmp (510)
[2015-07-23T14:50:24] DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=UTF-8 (511), window=1e00004
[2015-07-23T14:50:24] DEBUG1: request succeeded after 0.000000s
[2015-07-23T14:50:24] DEBUG1: selection conversion failed for target text/plain;charset=UTF-8 (511)
[2015-07-23T14:50:24] DEBUG1: no data for target text/plain;charset=UTF-8 (511)
[2015-07-23T14:50:24] DEBUG1: request selection=PRIMARY (1), target=UTF8_STRING (284), window=1e00004
[2015-07-23T14:50:24] DEBUG1: target UTF8_STRING (284)
[2015-07-23T14:50:24] DEBUG1: got data, 579 bytes
[2015-07-23T14:50:24] DEBUG1: request succeeded after 0.000001s
[2015-07-23T14:50:24] DEBUG: added format 0 for target UTF8_STRING (284) (579 bytes)
[2015-07-23T14:50:24] DEBUG: close clipboard 1
[2015-07-23T14:50:24] DEBUG: sending clipboard 1 seqnum=44
[2015-07-23T14:50:24] DEBUG: sent clipboard size=591
[2015-07-23T14:50:24] DEBUG1: thread 0x00000015 exit
@XinyuHou
Copy and paste doesn't work and I think it's the reason the client is crashing. I have log after log of the client timing out like this. Sometimes it segfaults, other times it just sits there for a long time.
[2015-07-23T17:26:19] DEBUG1: request failed
[2015-07-23T17:26:19] DEBUG1: can't get data for selection target TIMESTAMP (347)
[2015-07-23T17:26:19] DEBUG1: can't get ICCCM time
[2015-07-23T17:26:19] DEBUG: ICCCM fill clipboard 1
[2015-07-23T17:26:19] DEBUG1: sending clipboard chunk
[2015-07-23T17:26:19] DEBUG2: sending clipboard chunk start: size=15
[2015-07-23T17:26:19] DEBUG2: writef(DCLP%1i%4i%1i%s)
[2015-07-23T17:26:19] DEBUG2: wrote 16 bytes
[2015-07-23T17:26:19] DEBUG1: request selection=PRIMARY (1), target=TARGETS (346), window=2600004
[2015-07-23T17:26:19] DEBUG1: sending clipboard chunk
[2015-07-23T17:26:19] DEBUG2: sending clipboard finished
[2015-07-23T17:26:19] DEBUG2: writef(DCLP%1i%4i%1i%s)
[2015-07-23T17:26:19] DEBUG2: wrote 14 bytes
[2015-07-23T17:26:19] DEBUG2: can't read property 440 on window 0x02600004
[2015-07-23T17:26:19] DEBUG2: msg from server: DMMV
[2015-07-23T17:26:19] DEBUG2: readf(%2i%2i)
[2015-07-23T17:26:19] DEBUG2: readf: read 2 byte integer: 4 (0x4)
[2015-07-23T17:26:19] DEBUG2: readf: read 2 byte integer: 439 (0x1b7)
[2015-07-23T17:26:19] DEBUG2: recv mouse move 4,439
[2015-07-23T17:26:19] DEBUG2: writef(CNOP)
[2015-07-23T17:26:19] DEBUG2: wrote 4 bytes
[2015-07-23T17:26:19] DEBUG2: msg from server: DMMV
[2015-07-23T17:26:19] DEBUG2: readf(%2i%2i)
[2015-07-23T17:26:19] DEBUG2: readf: read 2 byte integer: 0 (0x0)
[2015-07-23T17:26:19] DEBUG2: readf: read 2 byte integer: 439 (0x1b7)
[2015-07-23T17:26:19] DEBUG2: recv mouse move 0,439
[2015-07-23T17:26:19] DEBUG2: writef(CNOP)
[2015-07-23T17:26:19] DEBUG2: wrote 4 bytes
[2015-07-23T17:26:19] DEBUG2: msg from server: COUT
[2015-07-23T17:26:19] DEBUG1: recv leave
[2015-07-23T17:26:19] INFO: leaving screen
[2015-07-23T17:26:19] DEBUG2: mapping state: 0
[2015-07-23T17:26:19] DEBUG1: request failed
[2015-07-23T17:26:19] DEBUG1: can't get data for selection target TARGETS (346)
[2015-07-23T17:26:19] DEBUG1: selection doesn't support TARGETS
[2015-07-23T17:26:19] DEBUG: available targets: STRING (31)
[2015-07-23T17:26:19] DEBUG1: request selection=PRIMARY (1), target=text/html (447), window=2600004
[2015-07-23T17:26:19] DEBUG1: request succeeded
[2015-07-23T17:26:19] DEBUG1: selection conversion failed for target text/html (447)
[2015-07-23T17:26:19] DEBUG1: no data for target text/html (447)
[2015-07-23T17:26:19] DEBUG1: request selection=PRIMARY (1), target=image/bmp (448), window=2600004
[2015-07-23T17:26:19] DEBUG1: request succeeded
[2015-07-23T17:26:19] DEBUG1: selection conversion failed for target image/bmp (448)
[2015-07-23T17:26:19] DEBUG1: no data for target image/bmp (448)
[2015-07-23T17:26:19] DEBUG1: request selection=PRIMARY (1), target=text/plain;charset=UTF-8 (449), window=2600004
[2015-07-23T17:26:19] DEBUG2: read property 443 on window 0x02600004: bytes=3
[2015-07-23T17:26:19] DEBUG1: target text/plain;charset=UTF-8 (449)
[2015-07-23T17:26:19] DEBUG1: got data, 3 bytes
[2015-07-23T17:26:19] DEBUG1: request succeeded
[2015-07-23T17:26:19] DEBUG: added format 0 for target text/plain;charset=UTF-8 (449) (3 bytes)
[2015-07-23T17:26:19] DEBUG: close clipboard 1
[2015-07-23T17:26:19] DEBUG1: thread 0x00000017 exit
[2015-07-23T17:26:19] DEBUG2: writef(CNOP)
[2015-07-23T17:26:19] DEBUG1: thread 0x00000018 entry
[2015-07-23T17:26:19] DEBUG2: wrote 4 bytes
[2015-07-23T17:26:19] DEBUG: open clipboard 1
[2015-07-23T17:26:19] DEBUG2: can't read property 440 on window 0x02600004
[2015-07-23T17:26:19] DEBUG1: request selection=PRIMARY (1), target=TIMESTAMP (347), window=2600004
[2015-07-23T17:26:19] DEBUG2: can't read property 440 on window 0x02600004
[2015-07-23T17:26:20] DEBUG1: request failed
[2015-07-23T17:26:20] DEBUG1: can't get data for selection target TIMESTAMP (347)
[2015-07-23T17:26:20] DEBUG1: can't get ICCCM time
[2015-07-23T17:26:20] DEBUG: ICCCM fill clipboard 1
[2015-07-23T17:26:20] DEBUG2: msg from server: CINN
[2015-07-23T17:26:20] DEBUG2: readf(%2i%2i%4i%2i)
[2015-07-23T17:26:20] DEBUG2: readf: read 2 byte integer: 0 (0x0)
[2015-07-23T17:26:20] DEBUG2: readf: read 2 byte integer: 414 (0x19e)
[2015-07-23T17:26:20] DEBUG2: readf: read 4 byte integer: 76 (0x4c)
[2015-07-23T17:26:20] DEBUG2: readf: read 2 byte integer: 0 (0x0)
[2015-07-23T17:26:20] DEBUG1: recv enter, 0,414 76 0000
[2015-07-23T17:26:20] INFO: entering screen
[2015-07-23T17:26:20] DEBUG1: request selection=PRIMARY (1), target=TARGETS (346), window=2600004
@nyetwurk
Do you not get any logging about clipboard 0?
@jtexp
If your assumption is correct, we should first try to use Debug log level. The log you posted is all about clipboard. We need to make sure it is caused by crash or connection drop first.
Btw are you using nightly 9b3602 and SSL?
@XinyuHou
I'm using that nightly, I'm not using ssl.
I will switch to DEBUG log level.
Not really sure how else I can help. I think tomorrow I will switch my server to Linux and client to Windows. It's a fix for me, not the software though..
@XinyuHou
No, no clipboard 0 activity. Let me dig around a bit and add some debug prints and try to figure out why.
I have the same issue.
The newest nightly build (rc5) didn't fix this issue yet.
For me I can't even copy from client to same client. I have to press ctrl+c several times in rapid succession to get it to copy.
Yeah, looks like I am seeing the same issue here.
More clipboard woes here. I have 1 iMac (10.10), one win (7 pro), and one lin (14.04), all running Synergy 1.7.4. iMac is the Synergy server, win and lin are clients.
I can:
I cannot:
No SSL, basic setup. Fresh install of 14.04.
I upgraded to 1.7.4 and still cannot paste from Linux client to Windows server. Windows to Linux does work. That's true regardless of the SSL setting.
The problem is still there in 1.7.4 . It's really annoying! Im using Ubuntu 15.05 as the server and Win 10 as the client
Just updated from something in 1.6 and now all of a sudden this isnt' working. I think the qa pre release needs some work and maybe volunteer testers (I would happily help). This is the second time I've updated in the last 6 months and the second time the upgrade broke something integral to my workflow and core to why I use this software. Last time it was fixed fairly quickly, but I'm honestly a little worried since this only got a "soon" priority... PLEASE please get some folks on board to help with linux dev...
Back to debugging the code: is the intent of the clipboard code to only get clipboard contents when the mouse moves off screen, or whenever something is added to the clipboard? If the former, it is being triggered too late; once the mouse leaves the screen, clipboard fill fails, and it is too late. It needs to be done right before the mouse leaves the screen, or when the clipboard actually gets data.
Given how fast my mouse settings typically are, how fast are my moves and
copy requirements and how loaded my computers usually are... Grabbing
content when mouse moves near screen frame is waaaay too late. Given some
large pastes and heavy load I'd be halfway on third screen before short
:wink:
So... grab data as soon as possible? with current RAM sizes, dowside would
be neglible - afer all my firefox uses 4GB and it's NOT biggest memory hog
on my system now (Chrome is).
2015-08-22 1:48 GMT+02:00 Nye Liu [email protected]:
Back to debugging the code: is the intent of the clipboard code to only
get clipboard contents when the mouse moves off screen, or whenever
something is added to the clipboard? If the former, it is being triggered
too late; once the mouse leaves the screen, clipboard fill fails, and it is
too late. It needs to be done right before the mouse leaves the screen, or
when the clipboard actually gets data.—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-133591924.
Pozdrawiam,
Hubert Kowalski
Well, I noticed that when the client's mouse is used to highlight, the clipboard is copied right away. If the server's mouse is used to highlight, nothing happens until it moves away from the client.
As suspected, if i move Client::leave m_screen->leave() after m_sendClipboardThread() it works. I have to add an ARCH->sleep() of course to delay the leave() as well.
Bottom line: you can't m_screen->leave() until the clipboard capture is done. So it either has to be done as SOON as the client copies something into the clipboard, or if you delay leave until the copy is done, the user will experience lag.
diff --git a/src/lib/client/Client.cpp b/src/lib/client/Client.cpp
index 33e2a6c..edeef60 100644
--- a/src/lib/client/Client.cpp
+++ b/src/lib/client/Client.cpp
@@ -262,8 +262,6 @@ Client::enter(SInt32 xAbs, SInt32 yAbs, UInt32, KeyModifierMask mask, bool)
bool
Client::leave()
{
- m_screen->leave();
-
m_active = false;
if (m_sendClipboardThread != NULL) {
@@ -277,6 +275,9 @@ Client::leave()
this,
&Client::sendClipboardThread,
NULL));
+ m_sendClipboardThread->wait();
+
+ m_screen->leave();
if (!m_receivedFileData.empty()) {
m_receivedFileData.clear();
BTW your tabbing sucks. sw=4 ts=8 or gtfo
So basically, may as well just call sendClipboardThread() directly, but then there is lag for large transfers.
So a few choices
1) figure out why the clipboard capture is failing after m_screen->leave()
2) split sendClipboard() into two separate things - capturing the clipboard and sending the clipboard to the server, and make sure to not call ->leave() until the capture is complete, then spin off the thread to send the data.
Any developers here at all? I am willing to do all the work, just would like to know which way would be preferred. Currently looking at 2), but the code is messy because of the crazy multiple clipboards. I could also add a mutex of some sort for the spun off thread to notify the client that the first half is done.. would be much easier to code than splitting up the function. Anybody have a preference?
@nyetwurk
Thanks for digging into this. Let me know if you post a branch to test.
Still waiting on advice for what makes the most sense to do architecturally. There are 4 or 5 different ways of fixing this bug.
@XinyuHou @nbolton
Any suggestions for @nyetwurk ?
In the mean time, anyone have suggestions how to get synergy to restart faster via systemd when synergy hangs due to this bug? Waiting upwards of 30s for a 20x a day crash is not nice.
Thanks @nyetwurk! I'd independently verified before finding this thread that it was the entering/leaving Screen that caused an abort on the clipboard copy that in turn caused an abort for the server. Really want to see this in a build soon.
That is a separate bug; unfortunately, there is no way to avoid it client side that I can tell.. my fix prevents a lot of the transfer aborts that sometimes kills the server, but NOT all of them. It is easy to reproduce, just have a lot of stuff in the clipboard, and quickly leave/enter/leave/enter the client etc.
updated patch to avoid signal()/wait() races
diff --git a/src/lib/client/Client.cpp b/src/lib/client/Client.cpp
index 33e2a6c..ef60baa 100644
--- a/src/lib/client/Client.cpp
+++ b/src/lib/client/Client.cpp
@@ -21,7 +21,6 @@
#include "../plugin/ns/SecureSocket.h"
#include "client/ServerProxy.h"
#include "synergy/Screen.h"
-#include "synergy/Clipboard.h"
#include "synergy/FileChunk.h"
#include "synergy/DropHelper.h"
#include "synergy/PacketStreamFilter.h"
@@ -75,7 +74,10 @@ Client::Client(
m_socket(NULL),
m_useSecureNetwork(false),
m_args(args),
- m_sendClipboardThread(NULL)
+ m_sendClipboardThread(NULL),
+ m_mutex(NULL),
+ m_condData(false),
+ m_condVar(NULL)
{
assert(m_socketFactory != NULL);
assert(m_screen != NULL);
@@ -107,6 +109,8 @@ Client::Client(
LOG((CLOG_NOTE "crypto disabled because of ns plugin not available"));
}
}
+ m_mutex = new Mutex();
+ m_condVar = new CondVar<bool>(m_mutex, m_condData);
}
Client::~Client()
@@ -125,6 +129,8 @@ Client::~Client()
cleanupConnecting();
cleanupConnection();
delete m_socketFactory;
+ delete m_condVar;
+ delete m_mutex;
}
void
@@ -262,8 +268,6 @@ Client::enter(SInt32 xAbs, SInt32 yAbs, UInt32, KeyModifierMask mask, bool)
bool
Client::leave()
{
- m_screen->leave();
-
m_active = false;
if (m_sendClipboardThread != NULL) {
@@ -272,11 +276,17 @@ Client::leave()
m_sendClipboardThread = NULL;
}
+ m_condData = false;
m_sendClipboardThread = new Thread(
new TMethodJob<Client>(
this,
&Client::sendClipboardThread,
NULL));
+ /* wait for fillClipboard()s to finish */
+ while (!m_condData)
+ m_condVar->wait();
+
+ m_screen->leave();
if (!m_receivedFileData.empty()) {
m_receivedFileData.clear();
@@ -382,9 +392,20 @@ Client::getName() const
}
void
-Client::sendClipboard(ClipboardID id)
+Client::fillClipboard(ClipboardID id, Clipboard *clipboard)
+{
+ assert(m_screen != NULL);
+ assert(m_server != NULL);
+
+ if (clipboard->open(m_timeClipboard[id])) {
+ clipboard->close();
+ }
+ m_screen->getClipboard(id, clipboard);
+}
+
+void
+Client::sendClipboard(ClipboardID id, Clipboard *clipboard)
{
- // note -- m_mutex must be locked on entry
assert(m_screen != NULL);
assert(m_server != NULL);
@@ -392,26 +413,21 @@ Client::sendClipboard(ClipboardID id)
// clipboard time before getting the data from the screen
// as the screen may detect an unchanged clipboard and
// avoid copying the data.
- Clipboard clipboard;
- if (clipboard.open(m_timeClipboard[id])) {
- clipboard.close();
- }
- m_screen->getClipboard(id, &clipboard);
// check time
if (m_timeClipboard[id] == 0 ||
- clipboard.getTime() != m_timeClipboard[id]) {
+ clipboard->getTime() != m_timeClipboard[id]) {
// save new time
- m_timeClipboard[id] = clipboard.getTime();
+ m_timeClipboard[id] = clipboard->getTime();
// marshall the data
- String data = clipboard.marshall();
+ String data = clipboard->marshall();
// save and send data if different or not yet sent
if (!m_sentClipboard[id] || data != m_dataClipboard[id]) {
m_sentClipboard[id] = true;
m_dataClipboard[id] = data;
- m_server->onClipboardChanged(id, &clipboard);
+ m_server->onClipboardChanged(id, clipboard);
}
}
}
@@ -673,8 +689,10 @@ Client::handleClipboardGrabbed(const Event& event, void*)
// if we're not the active screen then send the clipboard now,
// otherwise we'll wait until we leave.
+ Clipboard clipboard;
if (!m_active) {
- sendClipboard(info->m_id);
+ fillClipboard(info->m_id, &clipboard);
+ sendClipboard(info->m_id, &clipboard);
}
}
@@ -762,12 +780,24 @@ Client::onFileRecieveCompleted()
}
void
-Client::sendClipboardThread(void*)
+Client::sendClipboardThread(void * data)
{
+ Clipboard clipboard[kClipboardEnd];
+ // fill clipboards that we own and that have changed
+ for (ClipboardID id = 0; id < kClipboardEnd; ++id) {
+ if (m_ownClipboard[id]) {
+ fillClipboard(id, &clipboard[id]);
+ }
+ }
+
+ // signal that fill is done
+ m_condData = true;
+ m_condVar->signal();
+
// send clipboards that we own and that have changed
for (ClipboardID id = 0; id < kClipboardEnd; ++id) {
if (m_ownClipboard[id]) {
- sendClipboard(id);
+ sendClipboard(id, &clipboard[id]);
}
}
diff --git a/src/lib/client/Client.h b/src/lib/client/Client.h
index 1e5d42a..4493581 100644
--- a/src/lib/client/Client.h
+++ b/src/lib/client/Client.h
@@ -21,11 +21,13 @@
#include "synergy/IClient.h"
#include "synergy/IClipboard.h"
+#include "synergy/Clipboard.h"
#include "synergy/DragInformation.h"
#include "synergy/INode.h"
#include "synergy/ClientArgs.h"
#include "net/NetworkAddress.h"
#include "base/EventTypes.h"
+#include "mt/CondVar.h"
class EventQueueTimer;
namespace synergy { class Screen; }
@@ -162,7 +164,8 @@ public:
virtual String getName() const;
private:
- void sendClipboard(ClipboardID);
+ void fillClipboard(ClipboardID, Clipboard*);
+ void sendClipboard(ClipboardID, Clipboard*);
void sendEvent(Event::Type, void*);
void sendConnectionFailedEvent(const char* msg);
void sendFileChunk(const void* data);
@@ -223,4 +226,7 @@ private:
bool m_useSecureNetwork;
ClientArgs& m_args;
Thread* m_sendClipboardThread;
+ Mutex* m_mutex;
+ bool m_condData;
+ CondVar<bool>* m_condVar;
};
@nyetwurk
2) split sendClipboard() into two separate things - capturing the clipboard and sending the clipboard to the server, and make sure to not call ->leave() until the capture is complete, then spin off the thread to send the data.
I did a quick experiment similar to your solution before, but it didn't work out. I probably missed something that you didn't.
Please create a pull request, so we can make a branch for testing.
@xinyuHou
The ->signal()/wait() approach is kind of a hack, since ideally, I'd rather just inline the clipboard copy as a function that is called from the calling thread context, and not done in the clipboard thread... however, that would require keeping a clipboard vector - Allocated before the copy, then passed to the transmission thread, which would then be in charge of deallocation of the vector.. something I am not sure I want to do because of the way the thread is canceled.
Is the ->signal()/wait() method ok with you? If so, I will prepare a PR for it... if not, the alternative will take some time for me to code to make sure there aren't any memory leaks.
@nyetwurk
That brings back some memory. I remember when I did the experiment, I had trouble with deallocating memory just as you described.
signal/wait should be fine. But I'm not 100% confident with how CondVar works, so please don't completely rely on it or at least give it a timeout.
@XinyuHou
Understood, and I share your concerns. I'm a bit busy this week but I will try to add some sort of good timeout handling time permitting.
Alternately, maybe somebody can investigate why, exactly, ->leave() breaks fillClipboard()..
Added proper condVar locking and timeout:
https://github.com/nyetwurk/synergy/commit/5a74c85e67c939d589f58064c9f094385dc41731
@nyetwurk
Here is the nightly link for your pull request branch.
http://synergy-project.org/nightly?filter=nyetwurk-master-alpha-d186104
Could anyone test it? Please only leave comments that are related to this issue.
@XinyuHou
I adopted these fixes for openSUSE already. It fixed the issue in our case.
I tested this on Ubuntu 14.04 and it fixed my issue, though I have to copy twice sometimes.
@techninja
Can you provide a DEBUG1 level log (client side) of you having to copy twice? Thanks!
Sure thing. : http://pastebin.com/raw.php?i=uiMnsJdc
First copy seemed fine, next copy, moved to Win7 screen, clipboard didn't update, copied again, paste worked correctly. Did this about 2 times.
EDIT: Ignore the first bit of the log before I had turned on Debug1 level
Looks like the timeout isn't long enough for some reason
[2015-09-10T22:06:28] DEBUG1: recv leave
[2015-09-10T22:06:28] DEBUG1: thread 0x00000003 entry
[2015-09-10T22:06:28] DEBUG: open clipboard 0
[2015-09-10T22:06:28] DEBUG1: locked motif clipboard
[2015-09-10T22:06:28] DEBUG1: motif does not own clipboard
[2015-09-10T22:06:28] DEBUG1: unlocked motif clipboard
[2015-09-10T22:06:28] DEBUG1: request selection=CLIPBOARD (469), target=TIMESTAMP (478), window=5a00004
[2015-09-10T22:06:28] DEBUG1: target INTEGER (19)
[2015-09-10T22:06:28] DEBUG1: got data, 4 bytes
[2015-09-10T22:06:28] DEBUG1: request succeeded
[2015-09-10T22:06:28] DEBUG1: got ICCCM time 0
[2015-09-10T22:06:28] DEBUG: ICCCM fill clipboard 0
[2015-09-10T22:06:28] DEBUG1: request selection=CLIPBOARD (469), target=TARGETS (477), window=5a00004
[2015-09-10T22:06:28] DEBUG1: target ATOM (4)
[2015-09-10T22:06:28] DEBUG1: got data, 28 bytes
[2015-09-10T22:06:28] DEBUG1: request succeeded
[2015-09-10T22:06:28] DEBUG: available targets: MULTIPLE (474), TARGETS (477), TIMESTAMP (478), TK_APPLICATION (741)
[2015-09-10T22:06:28] DEBUG1: request selection=CLIPBOARD (469), target=text/html (589), window=5a00004
[2015-09-10T22:06:28] DEBUG1: request succeeded
[2015-09-10T22:06:28] DEBUG1: selection conversion failed for target text/html (589)
[2015-09-10T22:06:28] DEBUG1: no data for target text/html (589)
[2015-09-10T22:06:28] DEBUG1: request selection=CLIPBOARD (469), target=image/bmp (590), window=5a00004
[2015-09-10T22:06:28] DEBUG1: request succeeded
[2015-09-10T22:06:28] DEBUG1: selection conversion failed for target image/bmp (590)
[2015-09-10T22:06:28] DEBUG1: no data for target image/bmp (590)
[2015-09-10T22:06:28] DEBUG1: request selection=CLIPBOARD (469), target=text/plain;charset=UTF-8 (591), window=5a00004
[2015-09-10T22:06:28] DEBUG1: request succeeded
[2015-09-10T22:06:28] DEBUG1: selection conversion failed for target text/plain;charset=UTF-8 (591)
[2015-09-10T22:06:28] DEBUG1: no data for target text/plain;charset=UTF-8 (591)
[2015-09-10T22:06:28] DEBUG1: request selection=CLIPBOARD (469), target=UTF8_STRING (327), window=5a00004
[2015-09-10T22:06:28] DEBUG1: target UTF8_STRING (327)
[2015-09-10T22:06:28] DEBUG1: got data, 229 bytes
[2015-09-10T22:06:28] DEBUG1: request succeeded
[2015-09-10T22:06:28] DEBUG: added format 0 for target UTF8_STRING (327) (229 bytes)
[2015-09-10T22:06:28] DEBUG: close clipboard 0
[2015-09-10T22:06:28] DEBUG: open clipboard 1
[2015-09-10T22:06:28] DEBUG1: request selection=PRIMARY (1), target=TIMESTAMP (478), window=5a00004
[2015-09-10T22:06:28] DEBUG1: target INTEGER (19)
[2015-09-10T22:06:28] DEBUG1: got data, 4 bytes
[2015-09-10T22:06:28] DEBUG1: request succeeded
[2015-09-10T22:06:28] DEBUG1: got ICCCM time 0
[2015-09-10T22:06:28] DEBUG: ICCCM fill clipboard 1
[2015-09-10T22:06:28] DEBUG1: request selection=PRIMARY (1), target=TARGETS (477), window=5a00004
[2015-09-10T22:06:28] DEBUG1: target ATOM (4)
[2015-09-10T22:06:28] DEBUG1: got data, 28 bytes
[2015-09-10T22:06:28] DEBUG1: request succeeded
[2015-09-10T22:06:28] DEBUG: available targets: MULTIPLE (474), TARGETS (477), TIMESTAMP (478), TK_APPLICATION (741)
[2015-09-10T22:06:28] DEBUG1: request selection=PRIMARY (1), target=text/html (589), window=5a00004
[2015-09-10T22:06:28] DEBUG: timed out waiting for clipboard fill
[2015-09-10T22:06:28] INFO: leaving screen
[2015-09-10T22:06:28] DEBUG1: request failed
Looks like I screwed up the timeout handling. Sorry. I'll have a other patch time permitting, or somebody who knows how this CondVar works can take a look.
Either that or ArchMultithreadPosix waitCondVar() is broken.. which it looks like it might be.
Or maybe I didn't use Stopwatch right. Don't take this PR until I figure it out. Sorry everybody.
ArchMultithreadPosix waitCondVar() is definitely broken, it should retry loop until wait success() or the FULL timeout, not just 100ms
Returning false short of timeout is wrong. I have added a workaround to CondVarBase but I think it doesn't belong there.
Btw CondVarBase is also wrong. If timeout is <=0, it should still call wait() to unlock/lock mutex to give other thread a chance to grab the mutex if timeout=0 is used to busywait.
@nyetwurk
The pull request fixed the constant hangs I was experiencing. Thanks for the fix and continued effort.
@jtexp
Thanks for testing. Hopefully the PR goes upstream, but I'm sorta worried about ArchMultithreadPosix waitCondVar() .. not sure anybody is going to fix it.
@nyetwurk
I can pull your changes into the branch and let people test it when you are ready.
@XinyuHou
It is good to go but the CondVar change is a workaround for the underlying bug..
Clipboard copy doesn't work in my case, using:
Can any one test this nightly builds?
http://synergy-project.org/nightly?filter=nyetwurk-master-alpha-3eaefc
Will this fix any linux to windows disconnects?
I have been working around it for months now :/
On Mon, Oct 26, 2015 at 3:32 PM, Jerry (Xinyu Hou) <[email protected]
wrote:
Can any one test this nightly builds?
http://synergy-project.org/nightly?filter=nyetwurk-master-alpha-3eaefc
—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-151275976.
@webdawg
This pull request is supposed to fix clipboard issues which could cause disconnection.
I've installed the 3eaefcf nightly on my Linux server and client (both Ubuntu 15.10 x64). Initial copy/paste tests are working beautifully! Will report if I run into any issues.
I need the tar.gz source......for my archlinux box.
On Mon, Oct 26, 2015 at 3:40 PM, Jerry (Xinyu Hou) <[email protected]
wrote:
@webdawg https://github.com/webdawg
This pull request is supposed to fix clipboard issues which could cause
disconnection.—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-151277747.
@webdawg
Check this pull request.
Should I clone nyetwurk:master???
On Mon, Oct 26, 2015 at 3:52 PM, Jerry (Xinyu Hou) <[email protected]
wrote:
@webdawg https://github.com/webdawg
Check this pull request.4994 https://github.com/synergy/synergy/pull/4994
—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-151281405.
This has been working fine for me for the past hour and a half. Hundreds of switches between client/server and 10s of copy/paste operations in each direction. All of them worked, and no more disconnects. I also notice that the switch between client and server happens much faster now as well. Very happy with this fix! I've had this disconnect/clipboard issue several times per day for months now.
Do you know what I have to clone to get this fix you are talking about?
On Mon, Oct 26, 2015 at 5:00 PM, Andrew Ensley [email protected]
wrote:
This has been working fine for me for the past hour and a half. Hundreds
of switches between client/server and 10s of copy/paste operations in each
direction. All of them worked, and no more disconnects. I also notice that
the switch between client and server happens much faster now as well. Very
happy with this fix! I've had this disconnect issue several times per day
for months now.—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-151296538.
@webdawg
You probably need to clone Synergy first and then pull this pull request.
K.
I think you can just run git clone https://github.com/nyetwurk/synergy.git and install from that; the PR in question references the master branch on that repo.
I just had my first disconnect while trying to copy text from server to client. Same errors as before.
Removed to reduce scrolling.
However, other than that, this nightly build has been far more stable than 1.7.4.
Would need the server side log. Probably crashed and restarted.
I forgot I have 1.7.4 running on a second, rarely used client. If that's the cause of this problem, I'm sorry for the false alarm.
I had trouble getting the server log because the UI also has issues. This problem has been happening for me intermittently ever since 1.7.0 as well.

However, after maximizing it, I was able to figure out where the server log was, focused on that, CTRL+A, CTRL+C, and viola:
Removed to reduce scrolling.
[2015-10-27T14:49:06] INFO: entering screen
[2015-10-27T14:51:38] INFO: stopping synergy desktop process
[2015-10-27T14:51:38] INFO: process exited normally
[2015-10-27T14:51:40] INFO: starting server
The server stopped and took 2 mins to restart, which you can see in your client log.
Glad you could parse through all that. I certainly couldn't. Any more info you need from me?
Without knowing why the server died (i.e. debug or debug2 log) there isn't much to go on..
How would I obtain those?
Are @nyetwurk's changes going to be merged into master?
I've been running this build for about a week now, and no clipboard related crashes. Copy and paste work both ways (linux to linux).
@lipnitsk
We are under the process of releasing 1.7.5 which won't include this pull request. But we are planning to put it into 1.7.6.
If this pull request solves the problem on your side, please leave a note at https://github.com/synergy/synergy/pull/4994
All the credit goes to @nyetwurk
@XinyuHou I changed this to urgent, since there's a lot of people experiencing the problem.
Like alot!
On Mon, Nov 9, 2015 at 2:46 PM, Nick Bolton [email protected]
wrote:
@XinyuHou https://github.com/XinyuHou I changed this to urgent, since
there's a lot of people experiencing the problem.—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-155187787.
Ready for testing! :+1:
http://synergy-project.org/nightly?filter=v1.7.6-rc1-c97bd2c
Thanks @XinyuHou! :smile:
I have 1.7.6 RC1 installed and experienced the problem from client (Windows 10 64bit) to server (Linux Ubuntu 64bit). A temporary fix was to restart the server (aka re-initiate the connection). Let me know if there is anything I can do to provide the necessary logs in case this occurs again.
Edit: problem reoccurs (with server/client disconnect) multiple times a day.
Pre 1.7.6.RC1, this was 100% fail on my system always. With this release, works up to about 1/2K (approx. 512bytes). Anything over that still won't copy. (Still, this is a MAJOR improvement -- thanks guys!)
This seems to be fixed for me in 1.7.6 RC1. Copying from client to server (both 64 bit Fedora) works now for the very first time.
@seesemichaelj
@gorky
Do you use SSL?
Yes to both your questions.
Mike Seese
http://mikeseese.com On Mon, Nov 16, 2015 at 2:19 PM, Jerry (Xinyu Hou) < [email protected] [[email protected]] > wrote:
@seesemichaelj [https://github.com/seesemichaelj]
—
Reply to this email directly or view it on GitHub
[https://github.com/synergy/synergy/issues/4735#issuecomment-157141483] .[https://github.com/notifications/beacon/AAhhy_hggI871ZbMEDLqIujIdiWdW6QUks5pGiPGgaJpZM4Et4oG.gif]
@seesemichaelj
Please try this.
If the issue still persists, please send us some log info. You can use log to file feature.
On 11/16/2015 01:19 PM, Jerry (Xinyu Hou) wrote:
@gorky https://github.com/gorky
Do you use SSL?—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-157141591.No, I do not.
Regards,
Steve
@gorky
Please send us some log info. Check this wiki page.
I just upgraded to 1.7.6-rc1 and it fixed the clipboard in both directions. I have Ubuntu 15.10 64 on both the client and server. Thanks!
I still get crashes with 1.7.4-rc1 on Archlinux x64...can someone link me
the correct source that I should be testing with if there is something
better? Copy and paste works for a bit, but I can make it crash.
I really would like to help you guys debug this.
On Tue, Nov 17, 2015 at 1:50 PM, bwilson [email protected] wrote:
I just upgraded to 1.7.4-rc1 and it fixed the clipboard in both
directions. I have Ubuntu 15.10 64 on both the client and server. Thanks!—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-157501993.
Nick Bolton [email protected]
Nov 13 (5 days ago)
Ready for testing! [image: :+1:]
http://synergy-project.org/nightly?filter=v1.7.6-rc1-c97bd2c
Thanks @XinyuHou https://github.com/XinyuHou! [image: :smile:]
On Wed, Nov 18, 2015 at 8:57 AM, webdawg [email protected] wrote:
I still get crashes with 1.7.4-rc1 on Archlinux x64...can someone link me
the correct source that I should be testing with if there is something
better? Copy and paste works for a bit, but I can make it crash.I really would like to help you guys debug this.
On Tue, Nov 17, 2015 at 1:50 PM, bwilson [email protected] wrote:
I just upgraded to 1.7.4-rc1 and it fixed the clipboard in both
directions. I have Ubuntu 15.10 64 on both the client and server. Thanks!—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-157501993.—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-157739634.
Gare Calhoun
Mount Vernon, IA
phone: 319-895-6494
This build works for me for basic text copy and paste back and forth on Windows 10 server + Ubuntu 15.10 client for past several days. No crashes. :
http://synergy-project.org/nightly?filter=v1.7.6-rc1-c97bd2c
With rc1-c97bd2c x64 linux to x64 linux, I still get crashes.
On Fri, Nov 20, 2015 at 9:28 AM, garec [email protected] wrote:
This build works for me for basic text copy and paste back and forth on
Windows 10 server + Ubuntu 15.10 client for past several days. No crashes. :http://synergy-project.org/nightly?filter=v1.7.6-rc1-c97bd2c
—
Reply to this email directly or view it on GitHub
https://github.com/synergy/synergy/issues/4735#issuecomment-158432246.
This issue is back on 1.8.0-beta
clarification
win 10 server
ubuntu 15.10 client
1.7.6-rc1 works
1.8.0-beta breaks again
Side note: I'm not sure how easy it is, but given how often this (very important) feature gets broken, is there a way to write a set of automated tests protecting from the breakages in the future?
@shiyangcao - 1.8.0-beta is purely for enhancements, before we release it we'll include the fixes from 1.7.6!
@XinyuHou
I'm also seeing this issue but https://github.com/synergy/synergy/issues/4735#issuecomment-157154079 worked perfectly.
My Server is Windows and my client is Ubuntu.
...
Update... after a while the copy paste dies again. I'll run a logger tomorrow when I'm back at work.
I was also facing the same issue. But this bug #4735 fixed in latest version (http://synergy-project.org/nightly?filter=synergy-v1.7.6-rc2-a5acb0). Thanks
+1
I'm also seeing a client -> server clipboard not working w/ 1.7.5. Both Fedora 23 machines, happy to send logs if that helps.
@eriknelson
Please try our nightly to see if this issue is fixed
http://synergy-project.org/nightly?filter=v1.7.6-rc3-51705f7
Upgrading from synergy-v1.7.5-stable-fa85a24-Linux-x86_64.rpm to synergy-v1.7.6-rc3-51705f7-Linux-x86_64.rpm fixed the issue.
Thank you @XinyuHou!
@XinyuHou is there a plan to release 1.7.6 soon or will the change be incorporated into the 1.8 release only?
@lipnitsk
We are planning to release 1.7.6 soon. Now it's been sent out to our beta testers. After we release 1.7.6, we will merge fixes into 1.8 master branch. And the next 1.8 release would include all bug fixes and some enhancements.
Hi @XinyuHou, any estimates on the 1.7.6 release date?
Thanks!
@lipnitsk
We have some technical problems with our buildbots. We are working on it. After it's fixed, then 1.7.6 is ready to go.
This fixed my issue (http://tots.1o24.org/how-to-fix-copy-paste-clipboard-issue-on-windows-7-synergy-client/)
I have Synergy on Mac 1.8.2-stable-36cd521 and the exact same version is running on my Windows 10 Dell laptop.
If I copy/paste in either direction it is not working, plain-text, just 10 characters.
I've quit Synergy on both machines, restarted synergy, no difference.
Restarting my machines and starting from scratch does not get the copy+paste functionality working.
Due to my work computer and the refusal to allow me to upgrade the version of linux on it I am stuck using Version 1.4.12 between it and my laptop, I seem to be unable to Copy and Paste from the Sever to the Client. Is there a version of Synergy for Ubuntu 14.04.5 LTS that I can install that resolves the copy and paste issue?
@Buckweed666 we have official debs on our download page. https://symless.com/download or you can try a nightly build https://symless.com/nightly
v1.8.2 has a known bug with copying from client -> server on Mac OS X (but server -> client should be working fine). This will be fixed in the v1.8.3 release (currently aimed for next week.)
FWIW, opening the synergy client and hitting 'apply' on the host that is not getting clipboard contents fixes the problem at least temporarily.
After doing some more testing, seems the issue I was having can be narrowed down to copying from host, then pasting in the program "Pidgin" (a jabber xmpp client) on the client computer. I will go ahead and retest using your suggestion in the email. Thank you!
-Mikel
Sent from my T-Mobile 4G LTE Device
-------- Original message --------From: Harry Slaughter notifications@github.com Date: 11/28/16 4:46 PM (GMT-06:00) To: symless/synergy synergy@noreply.github.com Cc: Buckweed666 mikelbass@socket.net, Mention mention@noreply.github.com Subject: Re: [symless/synergy] Clipboard doesn't work from client to server
 (#4735)
FWIW, opening the synergy client and hitting 'apply' on the host that is not getting clipboard contents fixes the problem at least temporarily.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/symless/synergy","title":"symless/synergy","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/symless/synergy"}},"updates":{"snippets":[{"icon":"PERSON","message":"@hlslaughter in #4735: FWIW, opening the synergy client and hitting 'apply' on the host that is not getting clipboard contents fixes the problem at least temporarily.\r\n"}],"action":{"name":"View Issue","url":"https://github.com/symless/synergy/issues/4735#issuecomment-263419281"}}}
@hlslaughter this did the trick for me! (https://github.com/symless/synergy/issues/4735#issuecomment-263419281)
Having this problem with windows 10 as server and my mac as the client. I can copy from windows to mac but not mac to windows
[2017-02-28T17:23:22] INFO: starting new process
[2017-02-28T17:23:22] INFO: activeDesktop:Default
[2017-02-28T17:23:22] INFO: starting new process
[2017-02-28T17:23:22] INFO: drag and drop enabled
[2017-02-28T17:23:22] NOTE: started server, waiting for clients
[2017-02-28T17:23:22] INFO: watchdog status: ok
[2017-02-28T17:23:23] NOTE: accepted client connection
[2017-02-28T17:23:23] NOTE: client "LukeJolliffes-MacBook-Pro.local" has connected
[2017-02-28T17:23:23] INFO: switch from "DESKTOP-6AL0T2D" to "LukeJolliffes-MacBook-Pro.local" at 1679,228
[2017-02-28T17:23:23] INFO: leaving screen
[2017-02-28T17:23:23] INFO: screen "DESKTOP-6AL0T2D" updated clipboard 0
[2017-02-28T17:23:23] INFO: screen "DESKTOP-6AL0T2D" updated clipboard 1
[2017-02-28T17:23:23] INFO: switch from "LukeJolliffes-MacBook-Pro.local" to "DESKTOP-6AL0T2D" at -1898,255
[2017-02-28T17:23:23] INFO: entering screen
[2017-02-28T17:23:23] INFO: switch from "DESKTOP-6AL0T2D" to "LukeJolliffes-MacBook-Pro.local" at 1679,228
[2017-02-28T17:23:23] INFO: leaving screen
[2017-02-28T17:23:29] INFO: switch from "LukeJolliffes-MacBook-Pro.local" to "DESKTOP-6AL0T2D" at -1916,657
[2017-02-28T17:23:29] INFO: entering screen
[2017-02-28T17:23:29] INFO: screen "LukeJolliffes-MacBook-Pro.local" grabbed clipboard 0 from "DESKTOP-6AL0T2D"
[2017-02-28T17:23:29] INFO: screen "LukeJolliffes-MacBook-Pro.local" grabbed clipboard 1 from "DESKTOP-6AL0T2D"
[2017-02-28T17:23:29] INFO: screen "LukeJolliffes-MacBook-Pro.local" updated clipboard 0
[2017-02-28T17:23:29] INFO: screen "LukeJolliffes-MacBook-Pro.local" updated clipboard 1
Oh I wish this issue is solved.
On Tue, Feb 28, 2017 at 2:27 PM, lukeejay notifications@github.com wrote:
Having this problem with windows 10 as server and my mac as the client. I
can copy from windows to mac but not mac to windows[2017-02-28T17:23:22] INFO: starting new process
[2017-02-28T17:23:22] INFO: activeDesktop:Default
[2017-02-28T17:23:22] INFO: starting new process
[2017-02-28T17:23:22] INFO: drag and drop enabled
[2017-02-28T17:23:22] NOTE: started server, waiting for clients
[2017-02-28T17:23:22] INFO: watchdog status: ok
[2017-02-28T17:23:23] NOTE: accepted client connection
[2017-02-28T17:23:23] NOTE: client "LukeJolliffes-MacBook-Pro.local" has
connected
[2017-02-28T17:23:23] INFO: switch from "DESKTOP-6AL0T2D" to
"LukeJolliffes-MacBook-Pro.local" at 1679,228
[2017-02-28T17:23:23] INFO: leaving screen
[2017-02-28T17:23:23] INFO: screen "DESKTOP-6AL0T2D" updated clipboard 0
[2017-02-28T17:23:23] INFO: screen "DESKTOP-6AL0T2D" updated clipboard 1
[2017-02-28T17:23:23] INFO: switch from "LukeJolliffes-MacBook-Pro.local"
to "DESKTOP-6AL0T2D" at -1898,255
[2017-02-28T17:23:23] INFO: entering screen
[2017-02-28T17:23:23] INFO: switch from "DESKTOP-6AL0T2D" to
"LukeJolliffes-MacBook-Pro.local" at 1679,228
[2017-02-28T17:23:23] INFO: leaving screen
[2017-02-28T17:23:29] INFO: switch from "LukeJolliffes-MacBook-Pro.local"
to "DESKTOP-6AL0T2D" at -1916,657
[2017-02-28T17:23:29] INFO: entering screen
[2017-02-28T17:23:29] INFO: screen "LukeJolliffes-MacBook-Pro.local"
grabbed clipboard 0 from "DESKTOP-6AL0T2D"
[2017-02-28T17:23:29] INFO: screen "LukeJolliffes-MacBook-Pro.local"
grabbed clipboard 1 from "DESKTOP-6AL0T2D"
[2017-02-28T17:23:29] INFO: screen "LukeJolliffes-MacBook-Pro.local"
updated clipboard 0
[2017-02-28T17:23:29] INFO: screen "LukeJolliffes-MacBook-Pro.local"
updated clipboard 1—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy/issues/4735#issuecomment-283107399,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AByJBOSQ3LbSFT9dwmYBYwyq0Dsi6rXWks5rhFkbgaJpZM4Et4oG
.
I have the same problem except it completely prevents copy-pasting on the client while synergy is connected to a host.
Everytime I copy a string it is first pushed on the clipboard and then another empty string is pushed onto the clipboard above it. Thus preventing pasting the copied string back.
EDIT: Update that, it even prevents copy pasting on the host by overwriting the clipboard contents with an empty string.
Had same problem of failing to copy/paste from clipboard. The problem started recently upgraded my workstation from fedora 22 to fedora 26. After download of synergy source code, compiling my own version, still have copy/paste problem. To shorten this up, finally went back to old-school thinking... why not try starting synergys from /bin/sh (instead of /bin/bash):
/bin/sh -c 'synergys' &
That worked... copy/paste again working. Simple solution for me. See if this solves problem for others.
Have the same problems with a Gentoo Server and a Gentoo Client; maybe Klipper has something to do with it, no idea.
Most helpful comment
FWIW, opening the synergy client and hitting 'apply' on the host that is not getting clipboard contents fixes the problem at least temporarily.