So while I appreciate the thoroughness of this bug report and the effort in replicating the problem, this isn't something that's likely to get fixed without assistance. For a start, I don't have a spare Windows license for a VM that would let me set up the test case.

Having said that, it's not clear to me that this is a Meld problem anyway. Given that the test case is specifically against Xming and (according to the rhbz bug) can't be reproduced against RHEL or Fedora, I'm not sure why this shouldn't be considered an Xming issue.

Also, do other GTK+3 apps work?

Just to be clear, while Meld is certainly doing a bunch of its own drawing, it's just using standard GTK+ drawing calls, so other than try to reduce the number of calls we make, I don't even know what I'd do.

The window 7 version I am using is unregistered and just click the annoying register later to test this.

RHEL 7.3 on both sides - yes no issues
  with 16ms, 22ms, 54ms, 105ms, 222ms no issues

Win 7 & xming - Issues at 16ms for meld
  - putty-0.67 w/ enable X11 Forward enabled
  - Xming-6-9-0-31 install and test...
  with 16ms delay text displays, but no color (get circle bar in upper right).
    dropped 1ms at time, and displayed properly at 14ms
    15ms let run >60s after text visible, but still no color
  gnome-calculator with 16ms, 22ms, 54ms, 105ms, 222ms slower, but no issues


Win7 & xorg
  - cygwin xorg-server-1.19.0-1
  with 16ms delay text displays, but no color (get circle bar in upper right).
    dropped 1ms at time, and displayed properly at 13ms
  gnome-calculator works wth 22ms & 105ms (222ms didn't display)



Seems to be issue on the poll() looking at strace
0833 18:22:10.224591 wait4(30832, 0x7fe68affba64, WNOHANG, NULL) = 0 <0.000005>
30833 18:22:10.224659 wait4(30831, 0x7fe68affba64, WNOHANG, NULL) = 0 <0.000004>
30833 18:22:10.224681 select(0, NULL, NULL, NULL, {0, 100000} <unfinished ...>
30824 18:22:10.243350 <... poll resumed> ) = 1 ([{fd=7, revents=POLLIN}]) <0.024129>
30824 18:22:10.243387 recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0\312\226\f\0\0\1\241\1\0\0004\204R\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 <0.000005>
30824 18:22:10.243411 poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}]) <0.000376>
30824 18:22:10.243813 recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0\334\226\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 <0.000013>
30824 18:22:10.243873 recvmsg(7, 0x7fffdcaf3730, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000005>
30824 18:22:10.243919 poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=10, events=0}], 4, 0) = 0 (Timeout) <0.000025>
30824 18:22:10.243989 recvmsg(7, 0x7fffdcaf3c00, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000005>
30824 18:22:10.244013 recvmsg(7, 0x7fffdcaf3d30, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000023>
30824 18:22:10.244056 poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=10, events=0}], 4, 0) = 0 (Timeout) <0.000030>
30824 18:22:10.244345 poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}]) <0.000005>



Is there debug log or other application would like me to check?

There's no debug logging for this kind of stuff, no. I guess you could look at GTK+ debug logs, but I can't really say what you're looking for.

Again... to be honest, given the niche setup required here the chance that I'm going to set aside time to look at this is very, very low. If someone else does the investigation and finds some performance bottleneck I could look at then I might get to that, but I doubt there's going to be anything super-obvious.

Created attachment 343264 [details]
gdb thread bt

Understand the priority.

As FYI the Windows & Xming doesn't seem to have issue on RHEL 6 with meld-1.3.1-2.el6.noarch rpm. So I then installed that RHEL 6 epel version on RHEL 7, and it doesn't have issue there either.

strace of the loop seem to be in...

Process 16132 attached
restart_syscall(<... resuming interrupted call ...>) = 1
recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"\34\207\230I\f\0\0\1#\1\0\0\203G9\0\0\0\0\0\310\177@\2\330\330;\2\10\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(7, 0x7ffc957391f0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=0}], 4, 0) = 0 (Timeout)
recvmsg(7, 0x7ffc957396c0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, 0x7ffc957397f0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=0}], 4, 0) = 0 (Timeout)
poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{"\22\0\16\0\f\0\0\1#\1\0\0\6\0\0\0 \4\6\0\10\0\0\0\7\0\0\0\0\0\0\0"..., 1480}, {NULL, 0}, {"", 0}], 3) = 1480
poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"\34\207\253I\f\0\0\1#\1\0\0\242G9\0\0\0\0\0\310\177@\2\330\330;\2\10\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(7, 0x7ffc957391f0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=0}], 4, 0) = 0 (Timeout)
recvmsg(7, 0x7ffc957396c0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, 0x7ffc957397f0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=0}], 4, 0) = 0 (Timeout)
poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{"\22\0\16\0\f\0\0\1#\1\0\0\6\0\0\0 \4\6\0\10\0\0\0\7\0\0\0\0\0\0\0"..., 1480}, {NULL, 0}, {"", 0}], 3) = 1480
poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"\34\207\276I\f\0\0\1#\1\0\0\262G9\0\0\0\0\0\310\177@\2\330\330;\2\10\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(7, 0x7ffc957391f0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=0}], 4, 0) = 0 (Timeout)
recvmsg(7, 0x7ffc957396c0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, 0x7ffc957397f0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=0}], 4, 0) = 0 (Timeout)
poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{"\22\0\16\0\f\0\0\1#\1\0\0\6\0\0\0 \4\6\0\10\0\0\0\7\0\0\0\0\0\0\0"..., 1480}, {NULL, 0}, {"", 0}], 3) = 1480
poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"\34\207\321I\f\0\0\1#\1\0\0\321G9\0\0\0\0\0\310\177@\2\330\330;\2\10\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(7, 0x7ffc957391f0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=0}], 4, 0) = 0 (Timeout)
recvmsg(7, 0x7ffc957396c0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, 0x7ffc957397f0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=0}], 4, 0) = 0 (Timeout)
poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{"\22\0\16\0\f\0\0\1#\1\0\0\6\0\0\0 \4\6\0\10\0\0\0\7\0\0\0\0\0\0\0"..., 1480}, {NULL, 0}, {"", 0}], 3) = 1480
poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"\34\207\344I\f\0\0\1#\1\0\0\341G9\0\0\0\0\0\310\177@\2\330\330;\2\10\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 64



Attach gdb.out in case helps anyone too which  contains 'info threads' and 'thread apply all bt'

I find it hard to believe that this is a "niche setup". Xming is a pretty popular way to do X-forwarding. That being said, this is a regression, as it used to work in meld 1.6.1, but with meld 3, it no longer does so.

To provide some additional context, we're using this with Git and trying to look at diffs, and it hangs while loading the list of files. When I run xclock, it updates just fine. I have other servers on the same network that run on meld 1.6.1 that run just fine. What information can I help provide you? I'm just trying to encourage you to look at this, it would be really helpful to still be able to use meld in our environment.

(In reply to Jason from comment #5)
> I find it hard to believe that this is a "niche setup". Xming is a pretty
> popular way to do X-forwarding.

In 2017, just doing X-forwarding is a niche setup (albeit one I'd like to support). I appreciate it might not be so in your context, but given that it's been almost five years since 1.6 was released and there's been zero bug reports until now, I'm pretty okay to call this niche.

> That being said, this is a regression, as it
> used to work in meld 1.6.1, but with meld 3, it no longer does so.

You should feel free to bisect the problem. However, I suspect that it will occur when we switched from GTK+ 2 to 3. If it's something else then that might be more interesting.

(In reply to Jason from comment #6)
> What information can I help provide
> you? I'm just trying to encourage you to look at this, it would be really
> helpful to still be able to use meld in our environment.

As far as I'm concerned, what you're asking for here is free work on the kind of problem you'd get a commercial support contract for (which I don't provide).

Have you considered not updating Meld? or possibly trying to e.g., update to 1.8.x which still used GTK+ 2? or using VNC?

Kai,

Thanks for the polite response and I have to agree with your assessment. I'll try to both bissect the problem and see if we can use an older version of meld.

- Jason

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/113.