Linux client crashes randomly. Synergy 1.7.3
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.
Having the same issue. Not sure if it's related, but I'm also getting consistent clipboard corruption as well.
2015-05-31T23:01:11 ERROR: corrupted clipboard data, expected size=4 actual size=0
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/ClipboardChunk.cpp,116
The client generally seems to crash when moving the mouse between host and client.
Host: Windows 8.1 Pro 64 bit
Client: Arch Linux 64 bit
EDIT: I'm also seeing this in 1.7.3.
Yep, it feels like it's not really related to any clipboard action. Happens as well for me when moving between screens
Hi, I have the same issue. It only triggers after I copy something on the client, then switch screen one or two time.
I'm using lastest linux clients synergy-1.7.3-2 on archlinux (experienced with all my computers) and a stable 1.7.3 server on Windows 7. Same issue with nighly server builds, the problem seems to be on the client.
I don't use SSL encryption!
I switched back to 1.7.2 (client). At least it's kinda working now. No shared clipboard though
On my setup, the client 1.7.3-2 update broke my 1.7.2 server (that's why I upgraded) : looping between "new client connection" and "client disconnected".
But that's another problem...
Downgrading the client still breaks the clipboard and the connection is reset each time I move between screen with something in the clipboard
I think it is best is to focus on a working setup with a new client update and the 1.7.3 server.
Good luck... :)
EDIT: Here is what I experience with different archlinux client versions
Stable/Nighly 1.7.3 Server
_1.7.3-2 Client :_ Client crash, virtual bool XWindowsClipboard::open(IClipboard::Time) const: Assertion !m_open failed
_1.7.3-1 Client :_ Client crash, virtual bool XWindowsClipboard::open(IClipboard::Time) const: Assertion !m_open failed
_1.7.2-1 Client :_ Server ERROR: invalid message from client "xxx": DCLP + Connection restart
_1.7.1-2 Client :_ Server ERROR: invalid message from client "xxx": DCLP + Connection restart
_1.7.1-1 Client :_ Server ERROR: invalid message from client "xxx": DCLP + Connection restart
_1.6.3-1 Client :_ Server ERROR: invalid message from client "xxx": DCLP + Connection restart
Can confirm, this is very annoying. The client crashes frequently when moving between hosts.
Server: synergy 1.7.3, Gentoo Linux
Client: synergy 1.7.3, Arch Linux
same here, client and server both arch linux and 1.7.3
Same here:
virtual bool XWindowsClipboard::open(IClipboard::Time) const: Assertion!m_open' failed.`
on version 1.7.3
Trying to get everything that's possibly related cross referenced: https://github.com/synergy/synergy/issues/4735#issuecomment-108422245
Could anyone test this nightly?
http://synergy-project.org/nightly?filter=72060e5
NOTE: Re-run wizard after installation to get the lasted plugins.
@XinyuHou should we try from client, server side or both?
Testing it on Ubuntu 14.10 as server and Ubuntu 15.04 as client.
Clipboard works from server -> client but not the reverse. When I copy something on the client it is not transferred to the server.
The client also crashed a little while ago.
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 147 (DPMS)
Minor opcode of failed request: 6 (DPMSForceLevel)
Serial number of failed request: 55329
Current serial number in output stream: 55331
@iRet
Yes, please.
@Pontusfroding
Did you test with or without SSL?
Without SSL.
I have also increased the logging level, I will give you more information if it happens again. Anymore information you need, just ask me. :)
@Pontusfroding
Thank you!
What platforms are your server and client? I will try to reproduce it on my side.
Ubuntu 14.10 as server and Ubuntu 15.04
64 bit version, deb package
I think I was moving back forth pretty much when it crashed
@Pontusfroding
What did you copy into your clipboard when you move back and forth, text or image?
It must have been text, but I am not 100 % sure
@Pontusfroding
I'm be able to reproduce it once on my side. It seems intermittent. Does it act the same on your side?
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 20 (X_GetProperty)
Resource id in failed request: 0x2c0044c
Serial number of failed request: 18389
Current serial number in output stream: 18390
I havent had any more crashes yet, have to work a little bit harder so it will crash :+1:
Getting the crash issue going between windows -> linux mint... Trying the Nightly which seemed to reduce the issue but it does happen still and its relatively often. Just copying text.
Just realize I hijack this ticket with another issue.
virtual bool XWindowsClipboard::open(IClipboard::Time) const: Assertion `!m_open' failed.
This is caused by multiple thread tring to grab clipboard at the same time.
X Error of failed request: BadWindow (invalid Window parameter)
This is sequence number out of sync problem.
@cmellwig @dsemi @uZer @heipei @despairblue @elbowz
Could you please test this nightly?
@Pontusfroding
X Error of failed request: BadWindow (invalid Window parameter)
I created another ticket #4814 for this separate issue.
@XinyuHou Just tested with 415ac8e. The cursor on the client stops after switching between screens. No log entries though. After restarting the client app it works again for a while
@cmellwig
Thank you for testing.
What log level are you using? You can change it in settings.
I'm on debug
Last lines in my client log:
INFO: leaving screen
DEBUG: open clipboard 0
INFO: entering screen
DEBUG: ICCCM fill clipboard 0
DEBUG: available targets: STRING (31)
INFO: server is dead
INFO: leaving screen
And the server log:
INFO: entering screen
INFO: client "T20" has disconnected
DEBUG: active sides: 4
DEBUG: clipboard changed: lost ownership
INFO: screen "ws" grabbed clipboard 0 from "T20"
INFO: screen "ws" grabbed clipboard 1 from "T20"
Client: "T20", Server: "ws"
In this case the client seems to crash.
Earlier today the server crashed (no mouse movement possible until jumping to the win8 lockscreen via CRTL-ALT-DEL.
Earlier today the server crashed (no mouse movement possible until jumping to the win8 lockscreen via CRTL-ALT-DEL.
This sounds an issue we thought we have fixed. Are you using the nightly on server side as well?
I have some speculation about the first issue. But I need some experiments to prove it.
Yep, using 415ac8e on client and server. If you need additional info let me know. I'll try to get a log when the second issue occurs again.
@cmellwig
A log file would definitely be helpful.
Did you rerun wizard to get the latest plugin?
Yep, did run wiz on both after installing the nightly
Any updates on this? This bug is making Synergy almost unusable, as it will crash every other time when moving between hosts and I have to restart the server so the client will reconnect.
Small updste from my site after using 415ac8e for more than a week. The issue that windows (server) becomes unresponsive only occured once.
The linux client needs to be restarted at least once an hour.
Same here, Linux synergyc is unresponsive quite often.
I use MacOSX + Windows + ArchLinux, and only Linux synergyc has this problem.
I'm experiencing the same issue. I using client and server both running ArchLinux.
$ uname -a
Linux 4.0.7-2-ARCH #1 SMP PREEMPT Tue Jun 30 07:50:21 UTC 2015 x86_64 GNU/Linux
Synergy:
$ synergys --version
synergys 1.7.3, protocol version 1.6
Copyright (C) 2012-2014 Synergy Si Ltd.
Copyright (C) 2008-2014 Nick Bolton
Copyright (C) 2002-2014 Chris Schoeneman
Log is similar to one that noted in this issue, however I was able to get different output when actively used my clipboard:
2015-07-13T17:52:53 INFO: entering screen
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/Screen.cpp,113
2015-07-13T17:52:53 DEBUG: start receiving clipboard data
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/ClipboardChunk.cpp,102
2015-07-13T17:52:53 DEBUG: received clipboard 0 size=6892
/build/synergy/src/synergy-1.7.3-stable/src/lib/client/ServerProxy.cpp,561
2015-07-13T17:52:53 DEBUG: open clipboard 0
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,319
2015-07-13T17:52:53 DEBUG: empty clipboard 0
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,272
2015-07-13T17:52:53 DEBUG: grabbed clipboard 0
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,295
2015-07-13T17:52:53 DEBUG: add 1148 bytes to clipboard 0 format: 0
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,306
2015-07-13T17:52:53 DEBUG: add 5724 bytes to clipboard 0 format: 2
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,306
2015-07-13T17:52:53 DEBUG: close clipboard 0
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,354
2015-07-13T17:52:53 DEBUG: start receiving clipboard data
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/ClipboardChunk.cpp,102
2015-07-13T17:52:53 DEBUG: received clipboard 1 size=6892
/build/synergy/src/synergy-1.7.3-stable/src/lib/client/ServerProxy.cpp,561
2015-07-13T17:52:53 DEBUG: open clipboard 1
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,319
2015-07-13T17:52:53 DEBUG: empty clipboard 1
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,272
2015-07-13T17:52:53 DEBUG: grabbed clipboard 1
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,295
2015-07-13T17:52:53 DEBUG: add 1148 bytes to clipboard 1 format: 0
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,306
2015-07-13T17:52:53 DEBUG: add 5724 bytes to clipboard 1 format: 2
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,306
2015-07-13T17:52:53 DEBUG: close clipboard 1
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,354
2015-07-13T17:52:55 DEBUG: lost clipboard 1 ownership at time 50175158
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsScreen.cpp,1326
2015-07-13T17:52:55 DEBUG: lost clipboard 1 ownership at 50175158
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,108
2015-07-13T17:52:56 DEBUG: lost clipboard 0 ownership at time 50175604
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsScreen.cpp,1326
2015-07-13T17:52:56 DEBUG: lost clipboard 0 ownership at 50175604
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,108
2015-07-13T17:52:56 INFO: leaving screen
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/Screen.cpp,131
2015-07-13T17:52:56 DEBUG: open clipboard 0
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,319
2015-07-13T17:52:56 DEBUG: ICCCM fill clipboard 0
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,499
2015-07-13T17:53:08 DEBUG: recv grab clipboard 1
/build/synergy/src/synergy-1.7.3-stable/src/lib/client/ServerProxy.cpp,577
2015-07-13T17:53:08 DEBUG: open clipboard 1
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,319
2015-07-13T17:53:08 DEBUG: empty clipboard 1
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,272
2015-07-13T17:53:08 DEBUG: grabbed clipboard 1
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,295
2015-07-13T17:53:08 DEBUG: close clipboard 1
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,354
2015-07-13T17:53:08 INFO: entering screen
/build/synergy/src/synergy-1.7.3-stable/src/lib/synergy/Screen.cpp,113
2015-07-13T17:53:08 DEBUG: available targets: text/plain (580), UTF8_STRING (399), STRING (31), TEXT (398), text/html (584)
/build/synergy/src/synergy-1.7.3-stable/src/lib/platform/XWindowsClipboard.cpp,518
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 147 (DPMS)
Minor opcode of failed request: 6 (DPMSForceLevel)
Serial number of failed request: 8317
Current serial number in output stream: 8319
NOTE: stopping synergy desktop process
Here's a new one:
INFO: leaving screen
DEBUG: open clipboard 1
DEBUG: ICCCM fill clipboard 1
DEBUG: available targets: TIMESTAMP (289), TARGETS (288), MULTIPLE (287), UTF8_STRING (286), COMPOUND_TEXT (285)
INFO: entering screen
synergyc: xcb_in.c:848: _xcb_in_wake_up_next_reader: Assertion `pthreadret == 0' failed.
I've reverted the Linux synergyc client to version 1.5 / protocol version 1.5
and everything works perfectly.
(I had to revert the server version and clients on other systems as well)
@antekone what's your server OS? Wanted to do that as well but shift didn't work after a windows hotfix
Server is on Windows 7 x64, installed from:
synergy-1.5.0-r2278-Windows-x64.msi (SHA1 5d8193b5638911ca1800009a6abac493a1a3e85e)
Client on ArchLinux was compiled from the source (synergy-1.5.0-r2278-Source.tar.gz).
It might be the case that some newer version would also work, but this was my
previous one before the upgrade, so I've just reverted to this one.
My right client is ArchLinux, left client is MacOS X El Capitan, and
copy/paste works everywhere (I can also copy in OS X and paste on Linux, without
problems, both ways).
cheers, i't seems to be a workaround for windows 7 only though. no shift on the client with a win8 server as i suspected.
Just chiming in that I am experiencing this also. Synergy v1.7.3, Arch linux both server and client, SSL disabled. Problem occurs when ctrl+c on the client, 2-3 screen moves later client crashes, server fine. Occasionally I have a 2nd client - on OSX Yosemite, cant copy-paste from client -> server, but no client crash has ever occurred afterwards.
Using http://synergy-project.org/nightly?filter=6109a18 on Windows and 1.5.1 on Linux works fine for me as a workaround btw. No crashes for 24 hours.
E: Using 1.6.3 as Server and 1.5.1 as client now. This way I can use Photoshop again
Downgraded to 1.6.2/1.6.3 for now without any issues. Sad to see that synergy has become less reliable as a result of unnecessary features like builtin encryption :(
Running 1.7.3, same issue. Frequent client exits with
virtual bool XWindowsClipboard::open(IClipboard::Time) const: Assertion `!m_open' failed.
Both server and client are running under Arch Linux.
Updated to latest from git; has not crashed yet.
Upgraded to 1.8.0 on Arch linux both server and client, and have not been able to reproduce at all - neither client or server has crashed yet. Using synergy-git from AUR instead of synergy from official repos
Upgraded just my client using the synergy-git package in the AUR, left my Windows server on 1.7.3, haven't seen a crash yet. Will update if anything breaks, but so far it's looking good. It's nice to have clipboard sync back.
Had this issue too with Windows server 1.7.4 and Linux client (tried various versions from 1.4-1.7.3 with rpms from fedora21, copr). Upgrading the client to 1.7.4 with rpm from the synergy-project website fixed both the clipboard sync (server->client only, client->server is still broken) and seems to have fixed the !m_open assertion failure causing the client to crash.
I have arch linux (x86_64) with synergy-git (built today) as server and windows xp with a nightly build (also downloaded today) as client and this happens _every time_ you have changed the clipboard in the client and try to switch to the server...
synergys: /home/urjaman/aur/synergy-git/src/synergy/src/lib/synergy/Clipboard.cpp:72: virtual bool Clipboard::open(IClipboard::Time) const: Assertion `!m_open' failed.
I've been building this via ABS and my own PKGBUILD on Arch (x86_64). Just tested with v1.7.5-rc1-ceab3a8, and am still get this error.
I will try a v1.8.0 build later and test.
Can anyone test this nightly to see if the problem persists?
http://synergy-project.org/nightly?filter=synergy-v1.7.6-rc1-dcc1c
I have installed the nightly on a windows server and fedora client. Bidirectional clipboard is working for the first time in months. No crashes apparent within the first 10 minutes of use. I'll report back any problems if I encounter them.
Out of curiosity, what was the fix for this?
Shouldn't all issue closures be including the relevant commit?
@nyetwurk
09c2f88
If it's already open, call open again will fail. I think your pr solved the time racing problem which should also solve this problem.
Just chiming in, I switched to the Enlightenment WM today (both client and server) and cannot reproduce the bug at all. Bi-directional copy-paste works and cannot get it to crash :)
Edit: Arch Linux, Enlightenment WM, Light DM, Synergy 1.8.1 (from synergy-git in AUR)
@se1exin
Which version of Synergy are you using?
Build Version 20151130.r2417.7a207b4-1
Synergy 1.8.1
Can confirm this still exists in 1.8.1 as well. Arch Linux server with XFCE, and Windows 10 client.
Steps to reproduce are:
1) On the client, copy something to the clipboard.
2) Move the mouse to the server machine. Synergy immediately core dumps with the following error: Clipboard.cpp:72: virtual bool Clipboard::open(IClipboard::Time) const: Assertion `!m_open' failed.
I can provide more log files if needed. Also willing to help with testing.
@mikej96 I am seeing the same thing with synergy 1.7.6 on Fedora 23.
@mikej96 @jsight Me too. Win7 x64 client, Ubuntu 14.04 server. Synergy 1.7.6, protocol 1.6.
Another 'me too' chiming in. Win10 x64 client, Fedora 23 server. Synergy 1.7.6 on both.
@jsight @domhnallw @SirScott - my 'work around' for the crashing has been to let systemd start synergys, as systemd handles automatically restarting it when it crashes 100+ times per day.
@mikej96 That is actually a really good idea. Care to share your unit files?
@jsight sure. I pretty much followed the systemd config steps from here: https://wiki.archlinux.org/index.php/synergy#Arch_Linux_3
My unit file is:
[Unit]
Description=Synergy Server Daemon
After=network.target[Service]
User=%i
ExecStart=/usr/bin/synergys --no-daemon --config /etc/synergy.conf
Restart=on-failure[Install]
WantedBy=multi-user.target
I think I enabled it with something like: systemctl enable synergys@mike
@jsight FWIW, Just updated Fedora 23 -> 24 and this issue is no longer plaguing me.
Hi guys, could you test this nightly please?
@XinyuHou thanks for providing the nightly build to test with. So far I have not been able to reproduce the clipboard related crash issue with this build!!
I had been able to reproduce this issue every time with stable version 1.8.2, but haven't had a crash yet with this nightly. (My configuration is arch linux server, windows 10 client.)
If I happen to run into any issues with the nightly I will report back, but so far so good!!
Thanks!!
Thanks for testing @mikej96 . Note that there are still issues with this build, and we're working to resolve them.
Testing Bug #4740
SRV: synergy-v1.8.3-rc2-89c9c58-Linux-x86_64
CLN: synergy-v1.8.3-rc2-89c9c58-Windows-x64
Thes steps will test both #4740 and #5502. Because the bugs happen intermittently, this requires up to a day of testing, sorry about that.
Copied various plain texts both directions. Copied images. Synergy was stable.
One time, while copying 744kB of plain text from synergy log, from server to client, after presing ^V on client in Microsoft Word application, there appeared tons of asian signs instead of plain text. During paste operation, I was switching screens rapidly. Synergy stayed connected after pasting Chinese characters. It occurred only once. Next several attempts to reproduce Asian signs failed. See attached screen shot.
PASSED. Synergy worked stable, apart from one occurrence of pasting Chinese signs.
For what its worth, I have been running build 'b4fcffd' for 9 days now and have not had a single crash. I am using this build for my main work setup so I am at my desk using it for 9+ hours per day.
Previously it would literally crash over a hundred times per day.
The 89c9c58 has been a vast improvement for me as well. No crashes so far.
Most helpful comment
@XinyuHou thanks for providing the nightly build to test with. So far I have not been able to reproduce the clipboard related crash issue with this build!!
I had been able to reproduce this issue every time with stable version 1.8.2, but haven't had a crash yet with this nightly. (My configuration is arch linux server, windows 10 client.)
If I happen to run into any issues with the nightly I will report back, but so far so good!!
Thanks!!