Synergy-core: Clipboard doesn't work from client to server

Created on 28 May 2015  Â·  178Comments  Â·  Source: symless/synergy-core

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)

bug

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.

All 178 comments

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:

  • Copying "rich" text fails (#2909): A typical workaround is to copy your text into a plaintext program like Notepad _on the same machine first_, then re-copy it from there before moving to the other system to paste.
  • SSL limits clipboard to 1024 characters (#4712): Workaround is to disable SSL on all machines. There is also a nightly build if you're willing to test it.

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):

  • Disconnect after copy & paste #297 (closed)
  • Clipboard copies only plaintext between Mac and Windows #2909
  • Copy to clipboard only works from Notepad #3153 (closed)
  • Linux server,windows client-copy paste not working #3181 (closed)
  • Copy/Paste non plain text from Windows 7 (Server side) doesn't work on Linux (Ubuntu 12.04 Client Side) #4023 (closed)
  • Clipboard broken from Windows client to Mac server #4038
  • Copying loses formatting data (only the text is saved) #4143
  • Copy-Paste no longer works correctly between Mac and PC. #4224 (closed)
  • Clipboard broken between two Windows clients (only works one way) #4319
  • Clipboard broken from Windows 7 client to Windows 7 server #4356
  • Clipboard unreliable from Mac server to Linux client #4394
  • Clipboard from windows client to linux server does not work #4632 (closed)
  • Unable to send clipboard with size above 1KB when using SSL #4712
  • linux client crashes, XWindowsClipboard #4740
  • Copy/Paste Not working on Mac/Mac #4743
  • Buffer overflow detected on kubuntu 14.04 trusty / 1.7.3 #4761 (closed)
  • Error message from Excel moving pointer #4769
  • Copy-Paste from Windows 7 to Ubuntu Freezes the program I paste in #4773 (closed)
  • Copy Paste from Chrome(Server) to Client not working #4783 (closed)
  • Unable to cut and paste from an ubuntu client (15.01) to MS server (7) - using synergy 1.7.3 all across #4785 (closed)
  • clipboard doesn't work #4788 (closed)
  • Synergy freezed receiving clipboard data #4792
  • Copy/Paste causes crashes and loss of connection to server. #4829 (closed)

(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:

  • Ctrl-c on client A, ctrl-v on another client B - does not work. restart synergy on client B, repeat, works
  • ctrl-c on server, ctrl-v on client A - Does not work. Move to client B, ctrl-v works. move back to A - does not work. Reset synergy on A, repeat copy - orks for A does not work for B
  • copy on client B, paste on server - not works. restart synergy on B, server dies. restart synergy on server, resetart on B, Copy on B, client A dies, paste on serer works

    • Copy on client C - 100% percent guarantee that either sever dies or A/B during screen switching

  • Copy on Client B, wait ~10 s paste on A. Not works. Swithc back to B swithc back to A, paste works. after paste server dies within 1second

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:

  • Unable to send clipboard with size above 1KB when using SSL #4712

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.

http://synergy-project.org/nightly?filter=121080

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:

  • server and client were previously configured
  • start the server
  • start the client
  • the server stops immediately when client attempts to connect

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

  1. Stop synergy first
  2. Delete the old plugin directory
  3. Rerun wizard to download again

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

@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.

  • Client crashes from time to time due to the clipboard problem described above
  • Clipboard (copy & paste of plain-text) in direction from Linux to Windows doesn't work

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:

  • paste win->mac, mac->lin
  • paste mac->lin

I cannot:

  • paste lin-mac, lin-win
  • paste win-lin

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()..

@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:

  • Linux Ubuntu Gnome 14.04 as Server
  • Linux Ubuntu Gnome 15.04 as Client
  • Synergy 1.7.4 pro

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.

https://github.com/synergy/synergy/pull/4994

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.

TL;DR

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.

Server Log

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.
synergy_server

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

  1. Did you install 1.7.6-rc1 to both your server and the client?
  2. Do you use SSL?

@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]

  1. Did you install 1.7.6-rc1 to both your server and the client?
  2. Do you use SSL?

—
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.

  1. Stop running Synergy.
  2. Click File->Run wizard.
  3. Login and finish wizard.
  4. Click start on the main GUI.
  5. Do the same thing on both server and client.

If the issue still persists, please send us some log info. You can use log to file feature.

  1. Go to Edit->Settings->Logging.
  2. Tick Log to file.
  3. Specify the log file location (optional).
  4. Click Ok.
  5. Click Apply/Start.

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.

http://synergy-project.org/wiki/Sending_logs

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.

Was this page helpful?
0 / 5 - 0 ratings