Synergy-core: 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
https://github.com/symless/synergy-core/blob/409150ec4f75e78b7790ce7a0da55b2b1f0e03dd/src/lib/platform/XWindowsUtil.cpp#L1306

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 https://github.com/symless/synergy-core/issues/6481#issuecomment-512745333 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 [e-mail] 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
https://github.com/symless/synergy-core/issues/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.

[ensilon]

Since issue #6481 duplicates this one, it's worth noting that the problem description of this issue is much less broad than #6481, which is not just limited to QT apps and dragging. My experience is of random locking in every application. Can this be updated so everyone's clear on the issues?

[allanwmacdonald]

This is also happening in the open-source fork, barrier, so I suspect the problem is in common code among the two variants.
Ubuntu 18.04 client, Windows 10 server.

Please bump!

[Corben78]

I'm experiencing these freezes as well, server and client on Ubuntu 18.04 LTS linux, with gnome desktop. They occur again and again, are not related to any particular application on the client.

[bhjolly]

Same issue here.
Server: Win10
Client: Ubuntu 18.04 with XFCE
1gbps wired connection, no rhyme or reason as far as I can tell, client and server are both up to date and running 1.11.1-stable (just bought Basic), this is driving me nuts.

[datoux]

The bug might be related to the timeout in XWindowsEventQueueBuffer.cpp waitForEvent function. By default it is about 4 seconds. By fixing it to a smaller time (0.1 s) it has improved the freezing in my case. But it is a hack and might break things or have other consequences.

synergy_diff.txt

[allanwmacdonald]

This is just a thought; I have no idea about the code but from a user standpoint, I think the issue may be deeper than a mere timeout. I have also seen situations where the freeze is accompanied by a long sequence of repeated characters. Maybe the underlying issue is that the client is processing a whole bunch of repeated events in some event queue somewhere. Most of the time, these repeated events don't affect the appearance of the client but they have to be processed before a real mouse event gets processed. In other cases, these events adversely affect the client - repeated keystrokes for example.

[nhorvath]

I don't think the issue is repeated events, I think it's processing keydown
and there's a delay before the subsequent keyup being processed.

On Wed, Apr 8, 2020 at 5:53 PM allanwmacdonald [e-mail]
wrote:

This is just a thought; I have no idea about the code but from a user
standpoint, I think the issue may be deeper than a mere timeout. I have
also seen situations where the freeze is accompanied by a long sequence of
repeated characters. Maybe the underlying issue is that the client is
processing a whole bunch of repeated events in some event queue somewhere.
Most of the time, these repeated events don't affect the appearance of the
client but they have to be processed before a real mouse event gets
processed. In other cases, these events adversely affect the client -
repeated keystrokes for example.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy-core/issues/6487#issuecomment-611214176,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABIJXGEN65PDQLRTGQKW6TRLTW6VANCNFSM4HIPEA7A
.

[deanranderson]

Same issue here.
Server: Win10
Client: Ubuntu 18.04 with XFCE
1gbps wired connection, no rhyme or reason as far as I can tell, client and server are both up to date and running 1.11.1-stable (just bought Basic), this is driving me nuts.

As mentioned in the other linked issue, currently the best work around on Ubuntu 18.04 is to downgrade libx11 packages to ubuntu0.01 and hold/pin them. Syntax here: https://github.com/symless/synergy-core/issues/6481#issuecomment-512630902

[allanwmacdonald]

I don't think the issue is repeated events, I think it's processing keydown and there's a delay before the subsequent keyup being processed.
…
On Wed, Apr 8, 2020 at 5:53 PM allanwmacdonald @.*> wrote: This is just a thought; I have no idea about the code but from a user standpoint, I think the issue may be deeper than a mere timeout. I have also seen situations where the freeze is accompanied by a long sequence of repeated characters. Maybe the underlying issue is that the client is processing a whole bunch of repeated events in some event queue somewhere. Most of the time, these repeated events don't affect the appearance of the client but they have to be processed before a real mouse event gets processed. In other cases, these events adversely affect the client - repeated keystrokes for example. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6487 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABIJXGEN65PDQLRTGQKW6TRLTW6VANCNFSM4HIPEA7A .

@nhorvath: Oh I see. So, are you suggesting, then, that the keyboard server only sends the make code just once, even if the keyboard is sending "typematic" keys and then sends the break code as soon as it arrives? The server client then must wait for the break code and, if the break code doesn't arrive after a period of time, the client automatically starts repeatedly sending the make code events to the host OS until the break code arrives from the server? Is that about right? During the blocking condition, the break code gets delayed, inducing this auto-repeat mechanism. I presume this feature is to prevent excessive network traffic when the a key is being held down on the server keyboard.

[brianhks]

@allanwmacdonald That is what I saw when I attached a wire trace and dumped the debug logs. Periodically the client disconnects from the server which causes the apparent freezing if you are moving the mouse at that time. I code a lot using synergy so it will often disconnect right while I'm typing and the client gets the key_down event but no key_up so it behaves as you say and repeats the last key until the key_up comes through when it reconnects.

[nfstern]

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.

I logged in over there and clicked on the link that it also affects me. I encourage everyone who has this issue to do that.

[Jnewbon]

I have a new test build for you to try out, seem promising on eliminating the mouse freezing bug

Note this build also include other features Please see change log

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

You only need to install this on the client machine that is affected by the bug, you do not need to install this on the server machine

[nfstern]

I have a new test build for you to try out, seem promising on eliminating the mouse freezing bug

Note this build also include other features Please see change log

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

You only need to install this on the client machine that is affected by the bug, you do not need to install this on the server machine

I installed this and will reply back after a couple of days how well it's working. Thanks for this.

[allanwmacdonald]

I have a new test build for you to try out, seem promising on eliminating the mouse freezing bug

Note this build also include other features Please see change log

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

You only need to install this on the client machine that is affected by the bug, you do not need to install this on the server machine

I am giving this a try as well. Thanks!

[Corben78]

I have a new test build for you to try out, seem promising on eliminating the mouse freezing bug

You only need to install this on the client machine that is affected by the bug, you do not need to install this on the server machine

Server is running 1.11.1 stable and client running your test build. Can't tell about the freezes yet (so far none), but now the synergyc process is running with 100% cpu load all the time. Both machines are Ubuntu 18.04 LTS with all updates installed.

[deanranderson]

I see the same as @Corben78 . No freezes over the past 24 hours of usage, but 100% CPU even when the cursor isn't on the client.

[tavise]

Same as @Corben78. No freezes yet, but synergyc is 100% CPU on a core always. Ubuntu 18.04.04 LTS.
Update: The client just disconnected, server reports it dead. CPU usage went away, though the process is still running. It was connected and working for almost 1m 50s.

After a restart (with DEBUG logging enabled) it's been running for 20 minutes or so at 100%, but it hasn't dropped yet.

[allanwmacdonald]

I also see the same as @Corben78 - client at 100% cpu but no freezes since my last post.

[nfstern]

I've been using this patch for about 24 hours now. It seems to have fixed the issue. However, like others have posted above me, one of my cores is maxed out at 100%.

[Tehrasha]

Same results people are seeing above. Issue is resolved, but heavy on the CPU.

[allanwmacdonald]

@Jnewbon, I am just curious: I would like to see the source changes of this test build. I have cloned the git repository and discovered there is a branch named "issue-6487-mouse-freeze". Is that the branch that contains your changes?

[Jnewbon]

@allanwmacdonald The commit is linked just above my message. And yes that branch contains the commit.

The comments above have confirmed what I thought, the code I commented out seems to be the culprit but that code does more then just freezing the client.

I managed to run a client in debug mode and trigger a break during a freeze even which dropped me into that while loop. The comments around the while loop made mention of CPU usage, so although this solves the freezing issue it creates another issue that is arguable worse.

Ill need to spend a little more time on it, but now that this was found i may be able to get more done on it.

Shout out to @datoux who apparently found this code location about a month ago. I missed the comment and debugged my way there without seeing your comment. As well as some input from a support ticket that recently came in with some good information.

[Jnewbon]

So I spent some time looking into this and comparing commits.

With the fact that this is fixed by back dating libx11-6 to ubuntu0.1 I took another look into the xlib commit logs I find it very interesting that the while loop has a poll function in it and the change to xlib changed how polling worked.

The 2 commits in synergy that added the polling event have the comments
8b2f75f3 Fixed Issue #16: Intermittent delay problem with synergyc under Xwindows and
1ee6238a Hang Fix from Debian From 2009

Looking at that issue (#16) it describes this problem with unnerving similarity.

[Tehrasha]

I dont know if it is helpful at all, but on my setup the linux machine also has a mouse plugged into it.
If I moved that mouse when one of these stalls occurred, it immediately released mouse control back to synergy again, instead of waiting seconds for it to recover.

[Jnewbon]

Okay, After some more debugging and looking about i have another build for you to try, my testing shows that it solves the freezing and CPU usage problems.

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

React if it worked, or post if you find a problem.

[nfstern]

Okay, After some more debugging and looking about i have another build for you to try, my testing shows that it solves the freezing and CPU usage problems.

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

React if it worked, or post if you find a problem.

I'll give it a go and let you know.

Edit1
I just installed it and it has certainly resolved the CPU issue. Another nice aspect of that is my temperature readings dropped. I'll have to continue using it to see about the freezing issue. Thanks for this.

[tavise]

Installed. 100% CPU gone. Been running with it for about 2 hours.

I just had a repeating key occurrence, it lasted for about 15 letter repeats.

[Jnewbon]

@tavise Can you detail what program your using that the repeated char occurs in. Id like to try replicate the problem on my side.

[tavise]

@tavise Can you detail what program your using that the repeated char occurs in. Id like to try replicate the problem on my side.

Mainly IntelliJ, but if I happen to be in a shell window (bash), it'll do it there too. But since I spend most of my time in IntelliJ, that's where I usually see it. Hopefully you don't have to spend 2 hours typing in IJ to reproduce it! It's been 2 hours since it happened last, and it hasn't yet happened again.

In case it's relevant, I have 2 monitors hooked up to my laptop, so 3 screens total.

[tavise]

Day 2: Just had another occurrence of the repeating key issue in IntelliJ, and the client dropped connection with the server. I hit 'l' once:
nulllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll

[2020-05-05T11:06:16] NOTE: client "APTI5851-7540" is dead
[2020-05-05T11:06:16] INFO: jump from "APTI5851-7540" to "Sirius" at 960,540
[2020-05-05T11:06:16] INFO: entering screen
[2020-05-05T11:06:20] NOTE: accepted client connection
[2020-05-05T11:06:20] NOTE: client "APTI5851-7540" has connected

Unfortunately I wasn't running the client in DEBUG mode. I'll restart it in debug for the next time this happens.

Edit: Happened again, 50 minutes later.

[Jnewbon]

That looks like a network connection interruption and re-connection. Do those logs lines appear in the log every time the repeating bug occurs?

[tavise]

That looks like a network connection interruption and re-connection. Do those logs lines appear in the log every time the repeating bug occurs?

Nope. The repeat has happened 3x more today, none of the rest of them disconnected.

[Corben78]

Looks like when no server is available the snapshot from May 4th (1.12.0-shnapshot-a324957e) again causes 100% cpu usage. I have synergy autostarted, so it tries to connect to a server after the login, but as I'm using my notebook also when not at home, it won't find any.
Stopping synergy (via gui) ends the 100% usage of the synergyc process of course.

[tprk77]

I 'm experiencing the same issue. As I mentioned to support, this is the one thing that stops me from recommending Synergy to other people. I really like Synergy, so I'm glad this is being worked on!

My client is running Ubuntu MATE 18.04. The server is a Windows box. Both are on v1.11.1. (I've experienced this weird bug over multiple versions of Synergy, Ubuntu MATE, and Windows. It seems to happen very consistently for my setup.)

Synergy will basically hang up for about a second or two, as if experiencing a "lag spike". In reality, the Ethernet connection is fine. The Linux client is just going unresponsive. (Possibly as if waiting for a mutex or something). The weirdest part, is that it seems to be triggered by mousing over context menus. I don't get what context menus have to do with anything, but there you go.

I have looked at the network traffic in Wireshark. When the hangup occurs, the client just stops sending packets. Packets from the server are still flowing, every millisecond or so. This is eventually followed by a burst of packets from the client, about 150 messages over 5 milliseconds. After that, normal traffic resumes.

How to reproduce:

1. Install Ubuntu MATE.
2. Install Synergy, configure as client.
3. Using Synergy, start controlling the client.
4. Right click on top panel.
5. Hover mouse up and down over context menu, repeating for about 5-10 seconds.
6. Observe 1-2 second hang.

Note that the hang can happen without mousing over a context menu, but that seems to be a very repeatable way to trigger it. Please let me know if I can provide any other relevant information.

EDIT: I did try capturing logs, but the issue seemed to stop happening when I turned on Debug2. But Debug2 really degraded performance for me, so it might have still been happening and I just couldn't tell anymore. The issue is reproducible at Debug1, but there's no relevant output.

[Tehrasha]

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

Using this build, I can also confirm that the freezes have stopped, and that the CPU usage is back to normal. I have never seen an issue with repeating typed characters associated with this.

The only time I have ever experienced a keypress repeating in that manner was after seeing a 'synergy has stopped working' dialog, even though I never noticed a break in usage. Sometimes this resulted in two instances of synergy running at the same time, which caused all kinds of character repeats until I managed to kill one of them.

[albertomm]

1. Install Ubuntu MATE.

2. Install Synergy, configure as client.

3. Using Synergy, start controlling the client.

4. Right click on top panel.

5. Hover mouse up and down over context menu, repeating for about 5-10 seconds.

6. Observe 1-2 second hang.

Note that the hang can happen without mousing over a context menu, but that seems to be a very repeatable way to trigger it. Please let me know if I can provide any other relevant information.

I can reproduce this as well on a LinuxMint XFCE desktop. Moving the mouse up and down any context menu, and after a few seconds it starts hanging regularly.

My other client, a Windows 10 machine connected to the same linux server, works without any glitch (I even use it for gaming).

[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