Community
Participate
Working Groups
Build Identifier: M20090211-1700 we have a preferences page in a RCP application, where user can modify the maximum java heap size. when user clicks OK, the .ini file will get updated with the changed -Xmx value and then the RCP will be restarted. However, the old vm parameter is always being used. If the user restarts the RCP by double clicking on the exe file, the new vm parameter will be used. Reproducible: Always
This is still happening in eclipse 4.4. For our feature, we are using the addvmarg touchpoint upon plugin installation to increase the maximum heap size. After the installation is finished, users are asked to restart, however this won't result in using thee updated Xmx settings. Users have to completly close eclipse and start it again otherwise the feature might not work correctly.
I just hit this, in a situation that previously was masked by bug 522733 (which made restart on my box impossible to begin with). For Object Teams this is actually quite severe: when a user installs OTDT, several required entries are made into eclipse.ini and when those entries are not picked up, the user will launch into a badly broken workbench. In our case we need to set a -javaagent: and pass a system property. I can see that everything is correctly added to eclipse.ini (by using suitable declarations in p2.inf), but the restart is fubar. Looking into Installation Details > Configuration confirms that changes to eclipse.ini have not been picked up. Only clean exit and manual start result in a working system. Please s.o. let me know: is this an inherent restriction of "restart" or can this be fixed in the launcher? FWIW, I'm on linux.
(In reply to Stephan Herrmann from comment #2) > I just hit this, in a situation that previously was masked by bug 522733 > (which made restart on my box impossible to begin with). > > For Object Teams this is actually quite severe: when a user installs OTDT, > several required entries are made into eclipse.ini and when those entries > are not picked up, the user will launch into a badly broken workbench. > > In our case we need to set a -javaagent: and pass a system property. > > I can see that everything is correctly added to eclipse.ini (by using > suitable declarations in p2.inf), but the restart is fubar. Looking into > Installation Details > Configuration confirms that changes to eclipse.ini > have not been picked up. > > Only clean exit and manual start result in a working system. > > Please s.o. let me know: is this an inherent restriction of "restart" or can > this be fixed in the launcher? > > FWIW, I'm on linux. This only occurs with Webkit2, with webkitgtk 2.18. Only if SWT_WEBKIT2 is set(or webkit1 is not available). Not on Windows XP, and not on swt 3.4.. (just fyi)..
(In reply to Leo Ufimtsev from comment #3) > This only occurs with Webkit2, with webkitgtk 2.18. Only if SWT_WEBKIT2 is > set(or webkit1 is not available). > Not on Windows XP, and not on swt 3.4.. (just fyi).. I know that bug 522733 is specific to Webkit2. Are you saying also failure to respect changes in eclipse.ini is caused by Webkit2? (sounds surprising to me). I seem to be unable to test on webkit1 - unsetting SWT_WEBKIT2 doesn't help. Could you please let me know which package needs to be installed on ubuntu to run Eclipse on webkit1? This is what I have installed: ii libkdewebkit5 4:4.14.16-0ubuntu3.2 ii libkf5webkit5:amd64 5.18.0-0ubuntu1 ii libqt5webkit5:amd64 5.5.1+dfsg-2ubuntu1 ii libqtwebkit4:amd64 2.3.2-0ubuntu11 ii libwebkit2gtk-3.0-25:amd64 2.4.11-0ubuntu0.1 ii libwebkit2gtk-4.0-37:amd64 2.18.3-0ubuntu0.16.04.1 ii libwebkit2gtk-4.0-37-gtk2:amd64 2.18.3-0ubuntu0.16.04.1 ii libwebkitgtk-3.0-common 2.4.11-0ubuntu0.1 ii ocqt562-libqt5webkit5:amd64 5.6.2-1 ii python-pyqt5.qtwebkit 5.5.1+dfsg-3ubuntu4 ii qml-module-qtwebkit:amd64 5.5.1+dfsg-2ubuntu1
(In reply to Stephan Herrmann from comment #4) > (In reply to Leo Ufimtsev from comment #3) > > This only occurs with Webkit2, with webkitgtk 2.18. Only if SWT_WEBKIT2 is > > set(or webkit1 is not available). > > Not on Windows XP, and not on swt 3.4.. (just fyi).. > > I know that bug 522733 is specific to Webkit2. Are you saying also failure > to respect changes in eclipse.ini is caused by Webkit2? (sounds surprising > to me). Hmm. The issue occurs when eclipse shuts down, including restarts. I don't know about eclipse.ini changes. > > I seem to be unable to test on webkit1 - unsetting SWT_WEBKIT2 doesn't help. > Could you please let me know which package needs to be installed on ubuntu > to run Eclipse on webkit1? You can see which version of webkit you're using by setting: export SWT_LIB_VERSIONS=1 And it'll print something into the console about webkitgtk 2.4 or 2.18 being used. You could try SWT_WEBKIT2=0, but I generally avoid webkit1 (see below). > > This is what I have installed: > > ii libkdewebkit5 4:4.14.16-0ubuntu3.2 > ii libkf5webkit5:amd64 5.18.0-0ubuntu1 > ii libqt5webkit5:amd64 5.5.1+dfsg-2ubuntu1 > ii libqtwebkit4:amd64 2.3.2-0ubuntu11 > > ii libwebkit2gtk-3.0-25:amd64 2.4.11-0ubuntu0.1 > > ii libwebkit2gtk-4.0-37:amd64 2.18.3-0ubuntu0.16.04.1 > ii libwebkit2gtk-4.0-37-gtk2:amd64 2.18.3-0ubuntu0.16.04.1 > ii libwebkitgtk-3.0-common 2.4.11-0ubuntu0.1 > ii ocqt562-libqt5webkit5:amd64 5.6.2-1 > ii python-pyqt5.qtwebkit 5.5.1+dfsg-3ubuntu4 > ii qml-module-qtwebkit:amd64 5.5.1+dfsg-2ubuntu1 I see. On fedora webkit1 and webkit2 are: webkitgtk3.x86_64 2.4.11-5.fc26 @System webkitgtk4.x86_64 2.18.0-1.fc26 @System It looks like you already have webkit1 installed. With that said, you should probably avoid webkit1 as it crashes a lot. The crash issue can be avoided by just using a newer nightly eclipse. As a note, on Fedora 27 you can't even install webkit1 (gtk bindings) anymore.
(In reply to Leo Ufimtsev from comment #5) I'm not interested in webkit1 per se, I'm only interested in testing whether restart can pick up eclipse.ini changes if webkit2 is not involved. Normally, my configuration has this: org.eclipse.swt.internal.webkitgtk.version=2.18.3 With SWT_LIB_VERSIONS=1 and SWT_WEBKIT2=0 I don't see any webkitgtk version in my configuration. No reference to anything webkit. I would expect that on my system ii libwebkit2gtk-3.0-25:amd64 2.4.11-0ubuntu0.1 corresponds to what you listed as webkit1 on fedora. Still in this configuration, eclipse.ini changes are not picked up on restart. From this I conclude any connection to webkit2 is a red herring. So, question remains: is this an intrinsic limitation in the launcher, or can the launcher be fixed to pick up vmargs changes during restart?
(In reply to Stephan Herrmann from comment #6) > > From this I conclude any connection to webkit2 is a red herring. > > So, question remains: is this an intrinsic limitation in the launcher, or > can the launcher be fixed to pick up vmargs changes during restart? Hmm. I see. No idea, I only modify my eclipse.ini once when I setup my eclipse :-). I try to stay away from the launcher, but feel free to investigate.
Do you know if the launcher is reusing the existing JVM process or starting a new one? If the former than this bug would be systemic I guess.
(In reply to Stephan Herrmann from comment #8) > Do you know if the launcher is reusing the existing JVM process or starting > a new one? > If the former than this bug would be systemic I guess. Last time I touched it, I think the launcher is some C code that actually spawns the JVM itself. I debugged it at one point when we were working on wayland support. (Eclipse didn't start on wayland initially). My guess would be that a restart might not involve the launcher maybe? Thus the ini is not re-read. I don't know thou. The code calls C functions mostly dynamically without hard-links. If curious, I think this is the code: https://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/features/org.eclipse.equinox.executable.feature/library/gtk?id=a9044b3a6b51fa846973a4798ba1d073efe8697a I think args are handled here: https://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/features/org.eclipse.equinox.executable.feature/library/gtk/eclipseGtkCommon.c?id=a9044b3a6b51fa846973a4798ba1d073efe8697a But not sure if args are how the eclipse.ini is read. But it's food for thought I guess.
Can anyone in Equinox answer whether not picking up eclipse.ini changes during restart is a bug are an inherent limitation of the current design?
(In reply to Stephan Herrmann from comment #10) > Can anyone in Equinox answer whether not picking up eclipse.ini changes > during restart is a bug are an inherent limitation of the current design? Hello Stephan, In the mean time I've actually done quite fair bit of work on the eclipseGtk.c part of equinox launcher and got more acquainted with the code. (I added Dbus support into it). Not 100% sure, but from my initial investigation: I think the equinox launcher is not being used during a re-start. I.e, restart is a pure java thing and the C part (I think?) isn't actually ran. It's like launching a child eclipse, the launcher is not used for a child eclipse either. I've added a printf() to eclipseMain.c, and it's only ran when you open eclipse from launcher, not executed during restart. So via trivial evidence, eclipseMain.c (which deals with reading of eclipse.ini) is only ran when you actually start it from command line. So to have the eclipse.ini being re-read, it would probably require some additional code/logic. E.g implement a 'deep' restart of sort. As a note, heap size cannot be set during java runtime: https://stackoverflow.com/questions/763295/setting-jvm-heap-size-at-runtime So the approach of setting heapsize in options at runtime would require a sort of 'Deep' restart, that fully exits eclipse not just restarts it. IMHO: This kinda seems like a lot of work for a one-time configuration change. I would suggest to instead add a message/dialogue to the user and tell him to manually exit/start eclipse if they're making a JVM level configuration change. Like "Adjusting java virtual machine settings requires a manual exit and restart of the application" etc. With that said, I like the idea of adjusting heap size from preference, Eclipse might benefit from such a feature in platform imho. As this is not really a bug, but design limitation, changing importance to enhancement. Let me know if I can help further :-).
Thanks, Leo. I was afraid you'd say this. IOW, it's not a bug in the launcher as the launcher isn't even involved in the restart operation. => Moving on to platform to ask if they know about other options. In particular: I seem to recall there where scenarios, where update even swapped the executable, so perhaps platform already has means to somehow force a "deep restart"? Or should I say "cold restart"? NB, there are several options affected by this issue, heap size being only one of them, -javaagent being another.
This is mostly a limitation of the original design. There are two cases to be aware of here, which have to do with the "launchMode" 1) LAUNCH_JNI: The VM is started in-process using the JNI invocation API. In this case the whole launcher must restart, restartLauncher is called at the end of eclipse.c/_run() to spawn a new process. This will reinvoke the eclipse executable with a full command line including the vm args. In this case, the .ini file will be re-read, but the command line args over-ride the .ini file vm args. (Not sure if anything has changed with that?) 2) LAUNCH_EXE: The VM is started in a separate process by execing the java executable. In this case, the eclipse process itself does not need to exit, there is a while(running) loop in the main _run() function. The .ini file will not be re-read, we just loop and relaunch the java executable with the same command line as before (or with the command line returned from java via the shared memory.
Somewhere in the workbench is code around switch workspace that builds the command line to use and exits with code 24, which is the code to restart with a new command line. The launch uses the command line which is specified in the exit data. The eclipse "restart" command is exiting with 23, which tells the launcher to reuse the command it used before. Both of these then go through the process as described in my previous comment. One possible way to address this would be to have the workbench read the .ini file, build the full command line and restart with code 24.
(In reply to Andrew Niefer from comment #14) > One possible way to address this would be to have the workbench read the > .ini file, build the full command line and restart with code 24. This sounds very promising (to an outsider :) ). Do you envision this could be done for *every* restart, or would installation of specific updates need to set a specific flag to use this mode only when needed?
I would suggest that the current IWorkbench.restart() should perhaps stay the same as it is now since it is API for RCP apps. You could add a new restart method whose javadoc clearly says the workbench will try and read the .ini. I'm not sure how smart the workbench really wants to be with respect to VM args and such. (ie, what about maxPermSize, or modules, or whatever). It would then be up to the caller to choose which to call, whether it is an rcp app like in comment 0, or p2 itself after installing updates.
I filed bug 531112 for the p2 side of this.
*** Bug 357803 has been marked as a duplicate of this bug. ***
I just noticed this bug when updating a 2019-09 install to 2019-12, that was installed with Oomph. The splash screen keeps showing 2019-09 although the product is updated. Manually exiting and restarting shows the correct splash screen. See Bug 553862 that Oomph uses eclipse.ini settings to get the splash screen right.
(In reply to Rolf Theunissen from comment #19) > I just noticed this bug when updating a 2019-09 install to 2019-12, that was > installed with Oomph. > The splash screen keeps showing 2019-09 although the product is updated. > Manually exiting and restarting shows the correct splash screen. See Bug > 553862 that Oomph uses eclipse.ini settings to get the splash screen right. Yes, I noticed this too, and it happens too for an unzipped package that's updated the normal way. I don't think a restart really runs the eclipse.exe again and this is where the splash screen is started...
This is is because the workbench uses system properties to rebuild the string If you really do it your self (like the first comment of this case) you can fix it your self if really needed. our product uses the SetJvmAction of p2 touchpoints so we has the same problem i fixed it (pushed a patch) to SetJvmAction for this case: https://bugs.eclipse.org/bugs/show_bug.cgi?id=551378 in my gerrit change you can see what we did there: https://git.eclipse.org/r/#/c/152658/1/bundles/org.eclipse.equinox.p2.touchpoint.eclipse/src/org/eclipse/equinox/internal/p2/touchpoint/eclipse/actions/SetJvmAction.java so its all about changing the system properties that are used by the workbench.restart() to restart itself These are normally cached values of the ini file. Problem is uses can also give arguments on the command line and if restarted eclipse i think tries to restart exactly how it was started (that could be a bit different then the ini file) So i think we need some nice api for this (that also the touch point code could use) where we really can say, the ini file is updated and these are the updates also update your internal cached stuff.. But for now if you really are in full control (you update the ini file yourself) then you can also just look at the system properties that are used by eclipse to reconstruct it and adjust those. i think there are 3 that covers most stuff: eclipse.vm -> filename pointint to the vm dll/exe eclipse.vmargs -> the args that are after -vmargs entry in the ini file eclipse.commands -> the args that are before the -vmargs entry in the ini file.
i think this case is also a bit related to this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=552943 because if your customers have installed your eclipse product in a readonly place we have a way bigger problem Then the ini file that you adjust (you can adjust the ini that is in the real install dir) then that will not be picked up at all by eclipse... not sure how often that happens, but for unix based os's this is kind of the way to install stuff.
(In reply to Johan Compagner from comment #22) > (you can adjust the ini that is in the real install dir) You cannot ...
