Community
Participate
Working Groups
Build Identifier: M20100909-0800 (3.6.1) By default the Eclipse launcher attempts to use launchMode = LAUNCH_JNI. This can be changed at compile time by setting DEFAULT_JAVA_EXEC, or at runtime by using the -vm argument. If the -vm argument points specifically to a shared library the launcher will use LAUNCH_JNI, if it points to an executable it uses LAUNCH_EXE. This may be the same as bug 315985, which I'm not suitably empowered to re-open, except that bug didn't provide sufficient information to enable the Eclipse developers to reproduce the issue. Reproducible: Always Steps to Reproduce: Add to eclipse.ini (above -vmargs): -vm /usr/java/jdk1.6.0_21-i586/bin/java Obviously correct the path to java on your system. Run eclipse, passing a file to open ./eclipse /home/stephen/test.txt Note that the file does not get opened. If you leave Eclipse running and repeat the command then the file does get opened as expected. Now change the launch mode, for example by updating the "-vm" option to: -vm /usr/java/jdk1.6.0_21-i586/jre/lib/i386/client/libjvm.so Test again: ./eclipse /home/stephen/a-different-test.txt This time it works as expected.
I should add that we've observed this behaviour on Fedora Core 12 (using a 32bit JVM/32bit copy of Eclipse on both 32 and 64bit distributions of Fedora). GTK is from: gtk2-2.18.9-3.fc12.i686 I believe that the functionality works as expected, irrespective of the launch mode, on Win32 and OS X.
I have reproduced this now, but haven't gotten as far as finding the cause.
The problem is something like this: 1) Launcher process starts, sees there is no eclipse already running and sets up a timer to wait for this launch to make it far enough to receive the open file. 2) Launcher process forks a new child java process and then just waits for the child to exit. 3) Child Java process starts up eclipse. 4) The timer from (1) never gets hit because the launcher process is waiting on the child java process to finish. The gtk event loop is never spun here in the launcher process. The splash screen which normally does this for us is running over in the java process. Currently, we use waitpid on the child process, which just returns when eclipse exits. We will need to pass WNOHANG, which will return if the child has not exited. Then if the child is still running we need to spin the gtk even loop a little bit before sleeping and checking waitpid again. The event loop will need to spin for at least until the openFileTimeout expires or if we can detect success on the open file. After this we can go back to the old waitpid that will block until the child is done.
Note that this is not a problem on windows because there we are already spinning the event loop while waiting for the child process, this was because Windows 2k would hang in certain situations if we didn't respond to some events.
Created attachment 191635 [details] patch
I've just tested this patch and it does seem to resolve the issue for us - thanks!
I have released the fix, thanks for trying it out so quickly Stephen.
