Community
Participate
Working Groups
When I try to launch Eclipse on a Debian Linux distribution, it gets stuck in an infinite loop below. boolean iconic = false; Shell shell = parent != null ? parent.getShell() : null; /* INFINITE LOOP!!!!! */ do { OS.g_main_context_iteration (0, false); if (isDisposed ()) break; iconic = minimized || (shell != null && shell.minimized); } while (!mapped && !iconic); display.dispatchEvents = null; if (isDisposed ()) return; if (!iconic) {
I believe this is a regression from 3.0.1 where I don't see the problem. It happens about 80% of the times I launch Eclipse 3.1. I tried to modify/debug the Shell.java code a bit(checked it out from CVS HEAD), but I didn't discover anything except that the it appears as if GTK is deaf to the "setVisible" request. My X/GTK debugging skills are extremely limited, so even if there is a simple explanation to this problem, I wouldn't have expected to spot it. A bit more about my setup: - X server running under Microsoft Windows (Xming) - ssh -X tunnel to Debian box Øyvind
Would it be possible to try with other X servers besides Xming? I wonder if it is doing weird things with how and when it maps windows?
>Would it be possible to try with other X servers besides Xming? I tried it on CygWin/X and I was not able to reproduce the problem. Last I tested CygWin/X it didn't work on Eclipse for other reasons, but I'll try with CygWin/X for a while and see how that goes. >I wonder if it is doing weird things with how and when it maps windows CygWin/X and Xming shares a lot of code, so these may be subtle differences. I also see some window sizing problems(*) with Eclipse + Xming. Could it be that SWT-GTK assumes too much about the behaviour and timing of an X server? * e.g. the Debug dialog box is sometimes opened in a tiny window squeezed in the upper left corner of the desktop.. Øyvind
After about 2-3 minutes of use the CygWin/X server spontaneously terminated when I was using Eclipse... That leaves me without a working combination of X server & Eclipse 3.1. I'm stuck with Eclipse 3.1 now that CDT CVS HEAD requires Eclipse 3.1. Øyvind
I posted something about the problem to the Xming list: http://sources.redhat.com/ml/win32-x11/2004-q4/msg00086.html I'll be taking Eclipse 3.1 Motif for a spin to see if I have any more luck with that build. Øyvind
I tried Eclipse 3.1 Motif against CygWin/X and Xming. In both cases the requester where I select workspace was rendered correctly, but clicking on the buttons had no effect. Øyvind
I feel that an introduction of our new listener to this PR is called for. Alexander(ago@freedesktop.org) is the maintainer of Xming. Øyvind
I know, we've already been talking about it on IRC :)
With the new Xming snapshot (20050111) I can not reproduce the problem (startup loop). Though the eclipse resource window at first startup included not much more than the title bar and I had to manually resize it. I could not reproduce the problem with disappearing dialogs (which I had noticed sometimes even with 3.0.1) Øyvind, can you please report your experiences with the latest snapshot of Xming?
After some very cursory testing, I've seen: - It still gets stuck in an infinite loop in Shell.setVisible(). - No change for the "Debug" dialog. The "Debug" dialog is sometimes opened up in the upper left corner on my first monitor, and it is smaller than the title bar. When I resize it, things appear to work fine. I also see the "Debug" dialog much bigger than it should be(covering most of the screen) and in the wrong place. I've got a two monitor setup and I see it appearing on my left instead of the right monitor as it normally does because that is where I run Eclipse. - When I tested with the Eclipse 3.1 Motif version, the "Workspace Launcher" requester is still unresponsive. Øyvind
Window sizing problems may be the same problem as described in bug 77267. Eclipse relies on having good information about the size of the window manager frame using the function gdk_window_get_frame_extents(). This function works by walking up the window hierarchy and finding the last window which is a child of the root window and assuming its size is the size of the window's frame. Will this algorithm cause problems with the Xming window manager?
I'd just like to make it clear, in case it is a useful clue, that this is a regression from 3.0. Eclipse 3.0 and Xming are pretty stable combined. Øyvind
Reproduceable test case without running Eclipse. Attach file didn't work.... 1. download http://www.zylin.com/testswt.tar.bz2 2. Install Java & add "java" to the PATH 3. Run the following commands in an xterm window that is connected to a Linux box via Xming $ tar -xjvf testswt.tar.bz2 $ cd testswt $ sh run.sh It will hang after anywhere between 100-1000 iterations in shell.setVisible(). Øyvind
I was asked to add to this bug as well. Coming from Bug 86145, I can also repro something similar to the symptoms of Comment #6 above when trying to connect cygwin/X to a Solaris/Motif eclipse 3.0.1 build. I copied the test class for this bug and tried it on my configuration. What I get is that the screen shows up ok, no infinite loop (The "Iteration" loop never prints anything). But there are no events being dispatched that I can see. It just locks up tight on shell.open(). If I change shell.open and put: System.out.println("About to make visible " ); shell.setVisible(true); // shell.open(); System.out.println("now it's visible " ); Then I only get the first println and the same lockup.
I've done some debugging on the case: on the swt side - shell.setVisible() loops until mapped is set - mapped is set after the MAP event is received - MAP event is received in shellMapProc if the map event is not received it loops forever on the xming side - MapWindow is called - some checks for security is done which pass - MapEvent is sent - window is actually mapped if the window is already mapped MapWindow returns immediately without sending the event I suspect somewhere between MapWindow and shellMapProc the event gets lost. I'm sure if the network layer of xming is solid enough to be sure it is not the source of this error but the x11 protocol should notice any dropped events and packets Unless someone comes up with a test case which works predictably and not only after iteration 1900 and up (currently Øyvinds test is at iteration 5000) i can not do anything about it.
My 2 cents: this is a regression since Eclipse 3.0. Is it understood why this works under Eclipse 3.0? I'm not saying that there is a bug in Eclipse 3.1, but perhaps this is useful information in creating a new and improved testcase?
*** Bug 90413 has been marked as a duplicate of this bug. ***
Java 5.0 fixes the problem? I've been running Eclipse 3.1 for a couple of hours using Xming, which should have been plenty to reproduce the problem. This was with a fresh Debian install and Java 5.0. I used these instructions below to install Java on the Debian machine: http://serios.net/content/debian/java/with-java-package.php Murphys law dictates that the problem will occur as soon as I've claimed that it works, but hopefully I'm onto something. :-)
I believe I have run into this same problem with Eclipse 3.2.2 and Eclipse 3.3M6 on AIX Motif. I launch Eclipse and the workspace selector pops up, but won't respond to mouse or keyboard input. Here's what I'm using - Eclipse 3.2.2 or 3.3M6 (same result) Xming 6.9.0.23 (from http://www.straightrunning.com/XmingNotes/index.php) AIX 5.3.0.0 (from oslevel) JRE java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pap32dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20070201 (JIT enabled) J9VM - 20070131_11312_bHdSMR JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 The odd thing is that I can launch Eclipse with one alternate X Server, Reflection X 10.
This is most likely because of a bug in Xming. It periodicly checks if a different window manager has connected by selecting for SubstructureRedirect but does not process these events. It means some mapping and resizing request will get lost.
This bug was reported against a version that is not supported for very long time. We are sorry for not being able to look at it. Closing the bug now, please reopen if the problem still happens with 4.3.
