Community
Participate
Working Groups
I20061219-1300 (works in 3.3 M4 and all earlier builds) 1. start eclipse.exe using a Windows shortcut, e.g. C:\eclipse\drops\I20061219-1300\eclipse.exe -data workspace -vm C:\JavaSDKs\jdk1.4.2_12\jre\bin\java.exe 2. wait until the workbench is up 3. hit Ctrl+Break in the windows command console ==> nothing happens EXPECTED: stack dump of Java VM
It depends on bug 168645 because all shortcuts that I have and that do not use 'jre' don't work i.e. unless I go and change all my shortcuts I cannot even launch eclipse.
There are 2 things here: 1) the old behaviour relied on java.exe to create the console. The new launcher would want a -debug or -console. Bug 168775 will address this case. 2) The console is not connected properly when we do specify -debug or -console, see bug 167310. Even with 1.5.0 vms where the osgi console is working, we still don't get a stack dump. We still need to figure out what is wrong here.
As a workaround, I currently launch with: C:\java\jdk1.5.0_10\bin\java.exe <vmArgs> -jar <pathToEclipse>\plugins\org.eclipse.equinox.launcher_*.jar <eclipseArgs>
Jeff, this (and its blocking bug 167310) is something we should fix for 3.3.
I will investigate more for M7, but I still don't know what is wrong
This depends on the VM being used and how the vm is chosen: 1) (JNI invocation) no -vm specified: IBM 1.5 works, Sun 1.6 works 2) -vm pointing at java.exe: all vms work (see bug 168775) IBM's 1.4 doesn't even work when you launch java.exe directly. So the outstanding case is running Sun 1.4, 1.5 with JNI launching.
As mentioned before, eclipse.exe works or not depending on the vm. Starting in I20070430-0800, we now have an eclipsec.exe which is a console linked version of the launcher. All vm stack dumps should work with this launcher.
