Mouse freezes or key repeats on Linux client

[deanranderson]

Operating Systems

Server: Windows 10 v1809
Client: Ubuntu 18.04

Synergy Version

1.10.1

Steps to reproduce bug

1. Open a Qt-based app on the client (Dolphin, Konsole, Kate)
2. Click-and-drag a file icon or tab
3. Watch as mouse freezes for 5-10 seconds

Other info

• Seems to have started in 1.10 (or did not notice in Ubuntu 16.04 at least)
• Running KDE Plasma 5.12.7 and Qt 5.9.5
• GTK apps (Nautilus, etc) do not seem affected
• Occurs in both KDE and Gnome
• Client and server are connected via wired LAN (GigE)
• Disable Drag and Drop does not change behavior
• Disable shared clipboard does not change behavior
• Still an issue in Synergy 2
• No messages appear in either client or server log, even at DEBUG level
• Does not prevent me from using Synergy entirely, but it's added a lot of friction...
• Bug does not happen when the mouse is plugged into the client machine with Synergy still running.

[Jnewbon]

Managed to repeat the bug, I'm in the process of testing a QT update to 5.12.3, its possible this might solve the issue.

Updating the QT version has no effect.

[deanranderson]

So, poking around with DEBUG2 on I noticed the message in my client's log:

DEBUG2: can't read property 558 on window 0x03400060
...src/lib/platform/XWindowsUtil.cpp

That line is in XWindowsUtil::getWindowProperty() which seems to have a while loop that could very well be getting stuck. To test this, I just have the function immediately return true.

And... this seems to fix the freezing when dragging! However, I'm sure the hack is breaking all sorts of other features that I haven't noticed yet. Hopefully this helps with debugging.

Edit: I added some additional debug messages, and it seems that the call to XGetWindowProperty is just failing every call when dragging in a Qt window.

[Jnewbon]

I'm going to link this to #6481 as I feel they are very similar.

[deanranderson]

I think that's a safe bet. I've been running my hacked version on my client for a couple days and haven't noticed the other stalling issue. With that hack copy-and-paste from client to server doesn't work, but that's much less annoying.

[Jnewbon]

@deanranderson Thanks for the input, I have had some time to poke around the code.

The line where the issue starts to occur is this one

synergy-core/src/lib/platform/XWindowsUtil.cpp

Line 1306 in 409150e

XWindowsUtil::ErrorLock lock(display);

Adding a return before the line and the problem disappears, adding a return after and the problem comes back. However, removing that line doesn't solve the problem.

I have a feeling there is a mutex block going on between the different apps.

I think that's a safe bet. I've been running my hacked version on my client for a couple days and haven't noticed the other stalling issue. With that hack copy-and-paste from client to server doesn't work, but that's much less annoying.

When I was debugging that function I noticed that the function never gets through successfully, the function breaks out early as XGetWindowProperty() always fails. I need to find out what the function is actually used for, but this helps narrow it down. Thanks

[decarlo-cliff]

I've been running the version in the branch v1.10.2-dev-mouse-fix for several days now and I'm still seeing the mouse/keyboard freezing. Running the client build on Ubuntu 18.04 and the server on Windows 10 64-bit 1809.

[decarlo-cliff]

Just an interesting observation. When I set the server to check the clients every 1000 ms or so, the freezes seem to be much shorter in duration. In fact, when I get those strange keyboard presses over and over, it seems to stop if I move the mouse. I was getting freezes that lasted about 15-20 seconds which now seem to last only a second or two with the aggressive client checking set on the server.

[tavise]

I can confirm @decarlo-cliff 's change reduces the duration of the problem, but Synergy is still useless to me in this state. Even a single keypress repeated when I don't want it can have catastrophic results. Any progress on this issue?

[Jnewbon]

Giving this update here too, please check out #6481 (comment) for possible work around

[decarlo-cliff]

I actually switched to the KDE Plasma desktop with the sddm window manager a few days ago and I no longer seem to have synergy mouse/keyboard issues.

[jgindin]

I'm using KUbuntu, and dearly wish I didn't have the problem.

[jgindin]

Any chance this ticket will get worked on? I'm still stuck with multiple keyboards and mice on my desk right now :-(

[brianhks]

I know you duplicated #6481 to this ticket but I think this should be a duplicate of that. I posted a bunch of debug logs and it shows the client breaks communication with the server which causes the "freezing". And if it looses communication after a key down event I get a bunch of whatever the last letter was I typed before it gets the key up event. It also seems less prone to doing it right after the client is started.

[jgindin]

Will this be looked at?

[twitham93]

I would also like to see this fixed.

I use and refer Synergy to Ubuntu-based users frequently. I can't recommend the product in this state, and it is barely usable for me in it's current state.

Figured 1.11.0 might contain the fix since this seems like a pretty obviously big issue, but it doesn't appear so. This is on Ubuntu 18.04

Every time the issue occurs, there's logging about the server updating the clipboard or the client pulling the clipboard.

[deanranderson]

Since this seems to be a regression issue related to a libx11 package update within Ubuntu, I also filed a bug report with Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1859031

Maybe they will be more responsive than the Symless team.

[ensilon]

Does anyone know if this is a problem in 19.04 or 19.10?

[nhorvath]

I tried 19.04 a while back and it was a problem and there was no workaround since you can't downgrade the conflicting library.

…

On Wed, Jan 22, 2020 at 12:32 PM Ensilon ***@***.***> wrote: Does anyone know if this is a problem in 19.04 or 19.10? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6487?email_source=notifications&email_token=AABIJXDWQDNITPL4WA6HYUTQ7B7JVA5CNFSM4HIPEA7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJUN6YQ#issuecomment-577298274>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABIJXDXSBE5ZD4E6HRW5FDQ7B7JVANCNFSM4HIPEA7A> .

[tjaalton]

the backported patch in ubuntu 18.04 is from libx11 upstream, so feel free to file a bug there
https://gitlab.freedesktop.org/xorg/lib/libx11/issues

[emerysteele]

Pls fix this bug. Just bought synergy, very annoying. Using Windows 10 as server + Ubuntu 18.04 as client.

[adamwelsh]

Also experiencing this bug. Please bump priority.

[nfstern]

@Jnewbon,

I have been running with your latest patch for a few days now and it seems to have totally cleared up my freezing issue. I'm using Atom for my IDE and it used to freeze up at very annoying times. Copy and Paste of files was one use case although it didn't do it every time.

One of the things I had done a while back before I applied either patch was to roll back the libx11 packages as mentioned in 6481 by ArcherDs. Since my problem seemed to have cleared up, I went ahead and updated those packages. The patch continued to work fine. I no longer have a freezing issue nor do I have a cpu utilization issue. However, I have noticed very occasionally that when I right click on an item, it loses hold of the menu that pops up. I'm not even sure if this is related and it's not a big enough problem if it is that it disrupts my work flow.

Thanks for working on this patch.

[tprk77]

https://snapshots.symless.com/public/1.12.0-6487-snapshot2/

I've been trying this out today, and it seems to solve the problem!

🚀 Ship it! 🚀

[Jnewbon]

Looks like when no server is available the snapshot from May 4th (1.12.0-shnapshot-a324957e) again causes 100% CPU usage. - @Corben78

Running the master branch without the changes in for this issue causes the same problem, So ill create a new issue a bug as I confirmed its not related.

@tavise As I'm seeing others confirm they are seeing their issue resolved and the key repeating isn't very common across others with the cursor freeze, I'm fairly confidant what your experiencing is unrelated to this bug itself. Would you be able to create a new issue with the details of how to recreate it.

[andkramer]

Just have to let you know, i also had the repeating keys and freezes problem and using https://snapshots.symless.com/public/1.12.0-6487-snapshot2/ works like a charm! I hope it'll ship in next version :)

[Jnewbon]

A Slight update for this issue, it was highlighted to me that the fix i implemented may not actually fix the root cause, and as such a new fix has been suggested.

I have implemented this fix and created a new build. My testing shows this also fixes the problem, and I'm more inclined to use this version then the more hacky solution use before

https://snapshots.symless.com/public/1.12.0-6487-snapshot3/

Please try it out and confirm if it also solves the issues for you.

[deanranderson]

Just installed (and got to unpin libx11!) I'm not experiencing the Qt drag-and-drop freeze, though I may need to restart X to be sure. Will keep testing and let you know.

Thanks for squashing this bug!

[nfstern]

the fix i implemented may not actually fix the root cause,

@Jnewbon: Not sure what you're going off about here, I've been happily using your patch for weeks now with no issues and sure as heck fixed the root cause afaic.

[deanranderson]

the fix i implemented may not actually fix the root cause,

@Jnewbon: Not sure what you're going off about here, I've been happily using your patch for weeks now with no issues and sure as heck fixed the root cause afaic.

Fiddling with timings to mitigate a race condition != fixing root cause. This fix looks much better.

[andkramer]

i am trying it for 3h now, no key repeats and also no "stuck" modifiers when switching from linux to windows, which did previously occur with the older snapshot.

[Jnewbon]

the fix i implemented may not actually fix the root cause,

@Jnewbon: Not sure what you're going off about here, I've been happily using your patch for weeks now with no issues and sure as heck fixed the root cause afaic.

Fiddling with timings to mitigate a race condition != fixing root cause. This fix looks much better.

What I did only covered the problem, this new change fixes the cause of it (in testing)

Think of it as a broken pipe, I fixed the leak by wrapping it in duck tape, where as the new fix replaces the pipe with a new section. My bandage may solve the immediate problem but that might be at the cost of causing problems elsewhere.

The author of the fix explained why my fix was wrong, what the cause of the problem is and why his fix is the solution, and I agree with it.

I would rather this is fixed correctly even at the cost of undoing everything I have done to try and fix it. I have spent countless hours trying to trace the cause of this bug and essentially all that is going to be replaced in less then a week, but its the right thing to do to maintain a good, clean code base.

If I did something wrong call me out on it and suggest improvements. If part of the code is bad and you know a better way to do it lay out the reasoning. Criticism is one of the foundations for learning.

:)

[ensilon]

Well said!

[nfstern]

What I did only covered the problem, this new change fixes the cause of it (in testing)

Think of it as a broken pipe, I fixed the leak by wrapping it in duck tape, where as the new fix replaces the pipe with a new section. My bandage may solve the immediate problem but that might be at the cost of causing problems elsewhere.

The author of the fix explained why my fix was wrong, what the cause of the problem is and why his fix is the solution, and I agree with it.

I would rather this is fixed correctly even at the cost of undoing everything I have done to try and fix it. I have spent countless hours trying to trace the cause of this bug and essentially all that is going to be replaced in less then a week, but its the right thing to do to maintain a good, clean code base.

If I did something wrong call me out on it and suggest improvements. If part of the code is bad and you know a better way to do it lay out the reasoning. Criticism is one of the foundations for learning.

:)

Thanks for taking the time to explain. I'm sure you're right about all of this, it's just that after having to deal with that annoying bug for such an extended period of time, anything that made it go away was an enormous improvement in how it worked before.

From this user's perspective dealing with the daily frustration of the bug, it appeared resolved.

Criticism is one of the foundations for learning.

Yes.

[twitham93]

I would rather this is fixed correctly even at the cost of undoing everything I have done to try and fix it. I have spent countless hours trying to trace the cause of this bug and essentially all that is going to be replaced in less then a week, but its the right thing to do to maintain a good, clean code base.

Having seen many Engineers do the opposite of this, I applaud your conviction. Good on you!

[nbolton]

Fixed by #6693