Community
Participate
Working Groups
Build Identifier: 3.6.0 Our RCP application need to relaunch (not restart) the application. We therefore use org.eclipse.equinox.app.IApplication.EXIT_RELAUNCH and set the System property "exit.data" to some value ("\n-TalendProjectType DI\n-TalenRestart true"). Under Windows, Mac and Linux 32 bits, the relaunch works fine but under linux 64 bits it fails. The failure does not happend in java code but in the native launcher. You end-up with a navitve dialog box ( http://my.jetscreenshot.com/3027/20110517-1zwo-8kb.jpg ) diplaying an error icon and the "exit.data" value and that is it, press close and the application is closed. Reproducible: Always
The bug has been appearing on Ubuntu 10.4 64 bits and Open suze Linux linux-xrac 2.6.31.12-0.2-desktop x86_64 x86_64 x86_64 GNU/Linux openSUSE 11.2 (x86_64) 4.3.5 (KDE 4.3.5) "release 3" CPU Information Processor (CPU): Intel(R) Core(TM)2 Duo CPU T6670 @ 2.20GHz Speed: 1,200.00 MHz Cores: 2
I have updated the title because it also fails on Windows7 64bits with 64bit JVM.
Can you please post the value of the "eclipse.command" system property from when your RCP app is running? The value is the initial startup arguments separated by \n, we are particularly interested in if the -vm value is a .dll or .exe
here are the arguments when org.eclipse.equinox.launcher.Main.main(java.lang.String[]) line: 1383 si called on Linux suze 64bits. [-os, linux, -ws, gtk, -arch, x86_64, -showsplash, -launcher, /home/theusername/DEMOS/Talend-All-r60472-V4.2.1NB/Talend-linux-gtk-x86_64, -name, Talend-linux-gtk-x86_64, --launcher.library, /home/theusername/DEMOS/Talend-All-r60472-V4.2.1NB/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.0.v20100503/eclipse_1307.so, -startup, /home/theusername/DEMOS/Talend-All-r60472-V4.2.1NB/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar, -exitdata, 71001b, -console, -vm, /usr/bin/java, -vmargs, -Xms64m, -Xmx1536m, -XX:MaxPermSize=256m, -Xdebug, -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1716, -Dtalend.tac.version=4.2.1NB.60585, -jar, /home/theusername/DEMOS/Talend-All-r60472-V4.2.1NB/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar]
note the -exitdata 71001b that is not there under 32 bits platforms.
Actually, I suspect that you just don't have a good value for the "exit.data" system property. In general, you need to reconstruct the entire command line. The launcher is not necessarily going to re-read the eclipse.ini file since it thinks you are providing the whole command line. See org.eclipse.ui.internal.ide.actions.OpenWorkspaceAction#buildCommandLine from the org.eclipse.ui.ide bundle as an example where they are adding or modifying the -data argument. What I think is happening is the launcher is trying to restart using only the provided { "-TalendProjectType D", "-TalenRestart true" } arguments. It is somehow failing to start and then it is incorrectly interpreting the exit.data value as a custom error message to display. The value should be a '\n' newline separated list of all the arguments needed to start. You should probably actually use something more like exit.data = System.getProperty("eclipse.commands") + "\n-TalendProjectType\nDI\n-TalenRestart\ntrue\n-vmargs\n" + System.getProperty("eclipse.vmargs")
(In reply to comment #5) > note the -exitdata 71001b that is not there under 32 bits platforms. This is an indication of the method used to start the java vm. If you see this then the vm is being forked in a second process, otherwise it was started in the eclipse process by loading a vm shared library and using the JNI Invocation API. If the vm is forked (-exitdata present), then the eclipse.ini file is not being re-read. The actual eclipse process never stops on the relaunch, it just respawns a new child java process. This was always the standard relaunch behaviour since the beginning. Starting in Eclipse 3.3 when JNI launching was introduced, if the vm is not forked, then the eclipse process itself needs to exit and restart. In this case the eclipse.ini is actually re-read. In this case your partial command line will is more likely to work.
Thank you so much for all this information, I managed to make it work by setting the exit.data with the full commandline. Actually I did try that before submitting this bug but the commandline I built was wrong. I followed the code you mentioned for switching workspace and it is working fine. But the code is a bit puzzling to me as it is duplicating the "eclipse.vmargs" below the "eclipse.vm" and also at the end of the command line. Is this normal ? You may close the bug, sorry again for this and thanks for your detailed and prompt answers.
(In reply to comment #8) > But the code is a bit puzzling to me as it is duplicating the "eclipse.vmargs" > below the "eclipse.vm" and also at the end of the command line. > Is this normal ? Yes this is normal, I actually forgot about this when writing my first explanation (so the end of my comment #6 is slightly incorrect, and it is best to follow the OpenWorkspaceAction example). It is a historical result of launching the vm in a second process. In this case, the command line here is actually the command line that we are using to invoke the java executable. In this case the command line looks something like <java executable> <vm args> <jar/classpath> <program args> The <vm args> are consumed by java and Main only sees the program args. The -vmargs are appended again to the end of <program args> so Main knows what vm args were used so that they are available if we want to restart again. These appended vmargs will be stripped by Main and set as a system property "eclipse.vmargs", they are not passed on to the IApplication. In the case where we are using JNI invocation in-process, the launcher will manipulate this command line and use it to reinvoke eclipse.exe instead of using it to invoke java.exe
