Server logging crashes when switching with clipboard data #4792
Comments
|
Nope, no point using SSL in my home setup. |
|
A bit more detailed debug: DEBUG2: no-op from |
|
Trying to copy text from webpage (chrome on windows) to skype (linux) and it crashed every single time I'm trying to do that |
|
This is most likely a duplicate of one of these: https://github.com/synergy/synergy/issues/4735#issuecomment-108422245 |
|
@stiks http://synergy-project.org/nightly?filter=121080 If the issue persists, please send us both server and client log information. You can change log level to Debug in Edit->Settings on Windows. |
|
@XinyuHou Server: http://pastebin.com/4PBe8AQM It's still exists. I think problem is on server side, if you just copy text from Chrome and switch screen, nothing will happened. If you paste that text into plaintext windows (like IRC), it'll be fine. Some random characters will be included in the message, but server will not crash. When you try to post into skype or any other client (which support formatting), this will crash server. In my case, I'm trying to copy text from Chrome (Russian website) to skype. |
|
Sorry I can't reproduce this on my side. I used Ubuntu 14 as server and Windows 7 as client. Copied some texts from a Russian website from Chrome on client and paste into Skype on the server. Did you mean Russian text was the only problem or so was normal English texts? |
|
@XinyuHou Sorry for long reply, was trying to find best way to reproduce this issue. Now: On Windows 8.1 (client) Now there're 2 options: freeze or crash. FreezeSynergy server will stop responding, immediately after switching screen, but will be still running, this is most common issue for me atm. I have to stop manually kill server from console to restart it. Server logs: http://pastebin.com/z8XZ9KuJ CrashServer didn't freezed, and still running, but as soon as you try to paste that text, it'll crash. Server logs: http://pastebin.com/VQf5mnwg ServerI'm running server (synergys -d DEBUG2 -f) $ synergys --version |
xhou-wavefin
changed the title
xhou-wavefin
changed the title
|
Definitely getting issue here as well. I originally encountered this issue with SSL, so I turned ssl off. But the issue still persist(latest stable release and latest nightly for a week ago). Stiks, do you know of an earlier version of the server without the problem? |
|
I may have the same issue, though I encounter it when copying from Konsole on the client to Konsole on the server (sometimes to other applications but its harder to reproduce). Not using SSL, running latest stable - 1.7.4. As far as I can tell this is a regression introduced in 1.7.2 or 1.7.3 (I tested the latter and it has this problem) as when using 1.7.1 then everything works fine. |
|
Hi Guys, please try out our 1.7.5 release to see if it fixes this problem. |
|
|
@Lorquas |
|
@XinyuHou This is the synergy packaged by the fedora package maintainers, which I believe is built with your v1.7.6-stable tag. I'm willing to install any version using any method, to help you debug however. The FATAL debug level did fail. While the other debug levels failed with buffer overflows similar to the one in this and other referenced issues, i got this: synergys: /builddir/build/BUILD/synergy-1.7.6-stable/src/lib/synergy/Clipboard.cpp:72: virtual bool Clipboard::open(IClipboard::Time) const: Assertion `!m_open' failed. |
|
@Lorquas I think Debug build is more likely to have this buffer overflow issue. I'm currently working on an experimental branch to fix this issue. Will post the nightly later for testing. |
|
Please test this nightly for buffer overflow bug. |
xhou-wavefin
changed the title
Malcolmlowe
changed the title
Malcolmlowe
changed the title
Malcolmlowe
changed the title
|
So far, it's been running fine. Client: Server: |
Between Windows and Linux (server) 1.7.3
DEBUG2: readf(%1i%4i%1i%s)
DEBUG2: readf: read 1 byte integer: 0 (0x0)
DEBUG2: readf: read 4 byte integer: 157 (0x9d)
DEBUG2: readf: read 1 byte integer: 1 (0x1)
DEBUG2: readf: read 2 byte string: 62
DEBUG: start receiving clipboard data
DEBUG2: event: MotionNotify 243,521
after this daemon stop responding for incoming traffic, and no more log in debug mode
The text was updated successfully, but these errors were encountered: