Bug 1370627

Summary: meld fails to properly render over X11 forward tunnel with as latency increases to remote Xming Xserver
Product: [Fedora] Fedora EPEL Reporter: James Hartsock <hartsjc>
Component: meldAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: epel7CC: gilboad, kris.koorndyk, lkundrak
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-08 21:41:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description James Hartsock 2016-08-26 20:14:28 UTC 
Description of problem:
meld fails to properly render over X11 forward tunnel with as latency increases to remote Xming Xserver.  In general seems 16-22ms latency is enough.


Version-Release number of selected component (if applicable):
meld-3.11.0-1.el7.2.noarch
Both Xming 6.9.0.31 & Xming 7.5.0.62 (both tested)
Windows 7 & Windows 10 (both tested)


How reproducible:
Very with latency connection or by inflicting latency


Steps to Reproduce:
1. Need RHEL 7 system with meld, ssh, xauth
2. Need Windows system (vm works) with Xming & putty (w/ X11 Forwarding).
   Windows 7 & Windows 10 both seem to have issue
3. Start meld - should render fine.  Then close
   # meld /etc/passwd /etc/passwd
4. Now add some artificial latency (start with ~12ms)
   # tc qdisc replace dev eth0 root netem delay 12.23ms
5. Repeat step 3 & 4 an increase latency until meld fails to render and get just spinner.  16ms works for me, but another user too 22ms.


Actual results:
Once latency increases meld fails to render on the Windows Xming


Expected results:
meld should be able to handle this resonable latency, as issue initially reported by user forwarding X11 from USA to UK.


Additional info:

From windows cmd.exe you can use 'ping -t <rhel7-host>' to see the latency changes take effect from the tc command.
Comment 1 James Hartsock 2016-08-26 20:20:19 UTC 
Was unable to replicate this using another RHEL 7 or Fedora desktop.

Was able to clear the spinning by removing the latency too...
# tc qdisc replace dev eth0 root netem delay 0ms
Comment 2 Kris 2020-11-10 14:32:40 UTC 
I can confirm I'm having the same issue.

Using Xming on Windows 10 with X11 forwarding over SSH from a Fedora 30 machine, Meld v3.20.0 works fine while SSH'ing on the same LAN.  Attempting to do the same over VPN causes the same hanging spinner scenario.
Closing the app dumps the following traceback:

Exception ignored in: <function CachedSequenceMatcher.__del__ at 0x7f2fd2ca3b00>
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/meld/matchers/helpers.py", line 74, in __del__
    self.thread.join(self.TASK_GRACE_PERIOD)
  File "/usr/lib64/python3.7/multiprocessing/process.py", line 139, in join
    assert self._popen is not None, 'can only join a started process'
AssertionError: can only join a started process


Desperately need this working with the WFH orders.