Created attachment 4234 [details]
Wireshark capture compressed with WinZip

Per the request in the two linked messages, I have used Wireshark to capture
two X-Window sessions.	The captures are limted to the traffic between my PC at
192.168.45.229 and our AIX host at 192.168.40.59.  There are two captures, one
from CygwinX X-Server which has this problem and one from WinXServer X-Server
which does not.  The host program simply opens a single window, with a single
button, and waits for the window to be dismissed.  WinXServer worked correctly,
and I waited a few seconds between when the window displayed and when I
dismissed it which shows in the log.  The CygwinX log clearly shows things
worked correctly up to a point, then the session entered some type of loop
repeatedly sending requests and replys back and forth.

Please attach your /var/log/XWin.0.log as well.

Created attachment 4235 [details]
XWin.0.log for same time as Wireshark log

(In reply to comment #1)
> Created an attachment (id=4234)
> Wireshark capture compressed with WinZip

Thanks very much for these captures.

> The CygwinX log clearly shows things
> worked correctly up to a point, then the session entered some type of loop
> repeatedly sending requests and replys back and forth.

Indeed.  It seems to be repeatedly doing GetInputFocus (which is sometimes uses
as a client/server sync request), GetWindowAttributes and GetGeometry.

Any information you can develop on what actually the X client running on the AIX
host is doing at this point would be very useful (e.g. by running the
DialogClass1.class test app under some kind of debugger?)

Other things which would be useful:

* Install the xwininfo program (available in cygwin) and compare the output of
'xwininfo -all' on the "Dialog Example" window in the two cases.

* Ideally a wireshark trace of the AIX client connecting to the X.Org server
(ideally of the same version, 1.5) running under Linux (which according to other
reports works) (to reduce the variations due to differences in WinXServer which
I don't have the source for)

* I'm interested to know if the "Dialog Example" window gains focus when it
appears in these two cases?

* Is the problem also seen if you run Cygwin/X server in rooted mode (i.e.
without -multiwindow)?

* Can you test with the Cygwin 1.7 bet and the latest X.Org xserver for that
(1.6.3), just in-case this has been fixed upstream since 1.5.3?

Created attachment 4239 [details]
Pieces of requested information

Per the request for information, I was able to put together the following
today:

1) I have included the java program and compile instructions (file: Dialog Demo
Commands.txt) in the attached zip file.  Using the java debugger I have
determined it is entring the loop in the shell.open() call which is only tasked
with opening the dialog window.  I will have to install additional source files
to dig deeper.
2) Used xwininfo -all on both CygwinX (file: Dialog Demo Cygwin
xwininfo.txt)and WinXServ (file: Dialog Demo WinXServ xwininfo.txt) and
included the results of each.  Given that the hang was during the shell.open()
call, I removed the drawing of the button and and reran the xwininfo -all using
WinXServ (file: Dialog Demo WinXServ Open Only xwininfo.txt) for comparison.
3) Included screen captures of each window.  In short, yes the window does gain
focus when it freezes.
4) Tested without the -multiwindow with the same results.

I am working to get access to a Linux server for testing to generate a
wireshark report with the Linux server running the host program.  I also will
test with the latest Cygwin installed, just ran out of time today.  It may take
a day or 2 to get access to a Linux server.

(In reply to comment #5)
> Pieces of requested information

Thanks.  Due to this I managed to put together what I think is a reproduction of
the problem with the client running under Linux (after building the SWT Motif)

The client seems to get stuck in a loop in Shell.setVisible()

do {
	display.update ();
	if (isDisposed ()) return;
	iconic = minimized || (shell != null && shell.minimized);
} while (!isVisible () && !iconic);

isVisible() calls getVisible() which fetches the window attributes and checks
the visible state like this:

	if (attributes.map_state == OS.IsViewable && reparented) return true;

And as far as I can see 'reparented' is only set by a ReparentNotify event.

It seems to me the logic of this code is going to fail in 2 situations:
a) when we have no window manager running, so no reparent occurs.
b) when the window manager is rootless, and the parent window containing the
window frame is a native window, not an X window, so no reparent occurs.

Testing with Cygwin/X in rooted mode with twm running, and in an XDMCP session
to a KDE desktop, the DialogClass test application seems to work correctly.

(In reply to comment #6)
> (In reply to comment #5)
> > Pieces of requested information
> Thanks.  Due to this I managed to put together what I think is a 
reproduction of
> the problem with the client running under Linux (after building the SWT 
Motif)
> The client seems to get stuck in a loop in Shell.setVisible()
> do {
> 	display.update ();
> 	if (isDisposed ()) return;
> 	iconic = minimized || (shell != null && shell.minimized);
> } while (!isVisible () && !iconic);
> isVisible() calls getVisible() which fetches the window attributes and checks
> the visible state like this:
> 	if (attributes.map_state == OS.IsViewable && reparented) return true;
> And as far as I can see 'reparented' is only set by a ReparentNotify event.
> It seems to me the logic of this code is going to fail in 2 situations:
> a) when we have no window manager running, so no reparent occurs.
> b) when the window manager is rootless, and the parent window containing the
> window frame is a native window, not an X window, so no reparent occurs.
> Testing with Cygwin/X in rooted mode with twm running, and in an XDMCP 
session
> to a KDE desktop, the DialogClass test application seems to work correctly.

Before I pass this on to the Ecplise bugzilla posting, I just want to confirm 
that:
1) The code snippit is from the Eclipse java code.
2) The fix needs to be applied there.
3) If both of those are correct, do you think the other X Window programs work 
because of a 'work around' they have implemented for this environment?

(In reply to comment #7) 
> Before I pass this on to the Eclipse bugzilla posting, I just want to confirm 
> that:
> 1) The code snippit is from the Eclipse java code.

Yes

> 2) The fix needs to be applied there.

Well, this could be argued either way, I think :-)

> 3) If both of those are correct, do you think the other X Window programs work 
> because of a 'work around' they have implemented for this environment?

Yes, some change or work-around to meet SWT's expectations is certainly
possible, definitely in rootless mode.  I shall take a look at what can be done.

In the rooted mode, it's not quite so clear. I'm not sure if WinXServ has a
rooted mode.  If it does, it would be interesting to know if SWT works correctly
with it.

I have confirmed that running Cygwin/X as requested (in rooted mode with twm 
running) does work around the issue on our AIX system, indicating that you are 
on the correct track.  I have forwarded all of this information to the eclipse 
bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=36806) on this issue.

Created attachment 4254 [details]
Workaround for SWT Motif expecting all top level windows to get reparented

First draft of a patch to workaround this issue in interal WM (-multiwindow)
mode
This also contains a bit of tidying up related to internal WM event selection.

(In reply to comment #9)
> I have confirmed that running Cygwin/X as requested (in rooted mode with twm 
> running) does work around the issue on our AIX system, indicating that you are 
> on the correct track.

Thanks very much for testing this.

I've uploaded an XWin.exe based on 1.6.4, with the patch in #10 added at
ftp://cygwin.com/pub/cygwinx/XWin_swtmotif_workaround_20091004.exe.bz2, which
should workaround the issue in -multiwindow mode.

NOTE WELL: This is an Xserver for Cygwin 1.7, and will only work with that.

Please try it out if you can.

(In reply to comment #11)
> I've uploaded an XWin.exe based on 1.6.4, with the patch in #10 added at
> ftp://cygwin.com/pub/cygwinx/XWin_swtmotif_workaround_20091004.exe.bz2, which
> should workaround the issue in -multiwindow mode.
> NOTE WELL: This is an Xserver for Cygwin 1.7, and will only work with that.
> Please try it out if you can.

I have tested this on our AIX system and it has patched the issue.  I won't 
use the word resolved, because this is probably an a host SWT-Motif issue, but 
this definately works around the issue.  In addition to the test program, I 
have successfully started and used the Eclipse environment using this patch.

(In reply to comment #12)
> (In reply to comment #11)
> > I've uploaded an XWin.exe based on 1.6.4, with the patch in #10 added at
> > ftp://cygwin.com/pub/cygwinx/XWin_swtmotif_workaround_20091004.exe.bz2, 
which
> > should workaround the issue in -multiwindow mode.
> > NOTE WELL: This is an Xserver for Cygwin 1.7, and will only work with that.
> > Please try it out if you can.
> I have tested this on our AIX system and it has patched the issue.  I won't 
> use the word resolved, because this is probably an a host SWT-Motif issue, 
but 
> this definately works around the issue.  In addition to the test program, I 
> have successfully started and used the Eclipse environment using this patch.

I forgot to add, a Wireshark capture shows no extranious packets being 
exchanged.

(In reply to comment #12)
> In addition to the test program, I have successfully started and used the
Eclipse environment using this patch.

Excellent.

Yaakov, can you queue this patch up for the next Xserver release, please.

Added to queue for 1.6.5-1.

David, thanks for all your input; this would never have been fixed without it.

Patch shipped in 1.6.5-1; closing.

(In reply to comment #16)
> David, thanks for all your input; this would never have been fixed without it.

Indeed, thanks David for putting some time in on this or it would never have got
resolved.

(In reply to comment #17)
> (In reply to comment #16)
> > David, thanks for all your input; this would never have been fixed without 
it.
> Indeed, thanks David for putting some time in on this or it would never have 
got
> resolved.

Thank you both for your kind words.  Thank you very much for your work to put 
a patch together for this issue.  

Created attachment 4378 [details]
Discourage other WMs in multiwindow mode

The tidying up other WM detection code when adding SWT/Motif fix was rather
over-agressive and now allows other WMs to think they can start when the
internal WM is running.

Discourage them from doing that.

Reopening

Thanks; patch added to queue for 1.7.1-3.

Patch shipped in 1.7.1-3; closing.