Bugzilla – Full Text Bug Listing
| Summary: | Regression: Workspace Selection Dialog no longer shown due to cdt.tcf.ui / TCFSecurityManager starting early | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] TCF | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||||
| Component: | Debug | Assignee: | Project Inbox <tcf.debug-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Eugene Tarassov <eugene> | ||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | aleherb+eclipse, cdtdoug, tjwatson | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 0.4.0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I cannot reproduce so far. Do you know what triggers the activation of tcf.cdt.ui? Checking again in the debugger, it looks like OSGi is simply processing a StartLevelEvent, transitioning from startlevel 3 to startlevel 4. First all "lazy" bundles are processed, then the "non-lazy" ones. The o.e.cdt.tcf.ui bundle is part of the "non-lazy" ones. In my config, it is bundle #513 of 721 total. Perhaps the fact that I can 100% reproduce it and you can't is just by chance, due to the ordering of bundles in my config. (In reply to comment #2) > Checking again in the debugger, it looks like OSGi is simply processing a > StartLevelEvent, transitioning from startlevel 3 to startlevel 4. > > First all "lazy" bundles are processed, then the "non-lazy" ones. > The o.e.cdt.tcf.ui bundle is part of the "non-lazy" ones. > In my config, it is bundle #513 of 721 total. That's unexpected. It would mean tcf.cdt.ui got somehow marked as auto-start bundle. Could you check the entry for "org.eclipse.tm.tcf.cdt.ui" in the bundles.info file in your configuration area at <config-area>/org.eclipse.equinox.simpleconfigurator/bundles.info Could you also provide a bundle activation trace using following debug options: org.eclipse.osgi/monitor/activation=true org.eclipse.osgi/trace/activation=true org.eclipse.osgi/trace/filename=trace.log This should write a file "trace.log" in your current working directory. Created attachment 199408 [details]
Bundle Activation Trace
bundles.info looks like this:
org.eclipse.tm.tcf.cdt.ui,0.4.0.201106081058,../../configs/CDT/8.0.latest/eclipse/plugins/org.eclipse.tm.tcf.cdt.ui_0.4.0.201106081058.jar,4,false
Activation Trace is attached.
According to bundles.info, the o.e.tcf.cdt.ui bundle is definitely not marked as autostart, yet Equinox/OSGi does autostart the bundle. I tried to move away the entire configuration area, and have it re-generated on startup; the issue was gone. Yet comparing files between the old problematic configuration area and the new good one did not show any notable differences. I can still reproduce the issue with the old configuration area, but not with the new one. I'm reassigning the issue to Equinox/OSGi for now. Feel free to close WORKSFORME if you don't have a clue what could have caused Equinox to autostart the bundle erroneously. If you do want to investigate, I'm happy to provide more data eg zip up the old and the new config area, provide traces/debug info etc. Update: After a couple quit / restart cycles, also my new config area started to misbehave. The WS Selection Dialog was shown properly 3 or 4 times, but when starting the 5th time, the default workspace was used, without having anything changed in the configuration. So it looks like Equinox/OSGi behaves non-deterministic here. Again, I'm happy to provide more details. My guess is that someone is calling Bundle.start on the org.eclipse.tm.tcf bundle other than simple configurator and the persistent start bit is getting set. Note that when setting the following trace option: org.eclipse.osgi/monitor/activation=true The trace message is only written to standard error. You should see messages like this when a bundle calls a persistent Bundle.start(). So unfortunately you would have to keep capturing the output of this until you reproduce it again from a clean configuration. java.lang.Exception: A persistent start has been called on bundle: org.eclipse.core.runtime_3.7.0.v20110110 at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:306) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291) at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:312) at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:108) at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:129) at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:143) at org.eclipse.equinox.internal.simpleconfigurator.Activator.start(Activator.java:48) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1130) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) The stacktrace in comment 7 is an example of what you should see in standard error when org.eclipse.osgi/monitor/activation=true trace option. Created attachment 199417 [details]
Persistent Start in activation log
Tom, it looks like you're right as per attached activation log the TCF Launch Configuration Dialog:
java.lang.Exception: A persistent start has been called on bundle: org.eclipse.tm.tcf.cdt.ui_0.4.0.201106081058
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:306)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
at org.eclipse.tm.internal.tcf.debug.ui.launch.TCFLaunchContext.getLaunchContext(TCFLaunchContext.java:42)
at org.eclipse.tm.internal.tcf.debug.ui.launch.TCFMainTab.setDefaults(TCFMainTab.java:451)
at org.eclipse.debug.ui.AbstractLaunchConfigurationTabGroup.setDefaults(AbstractLaunchConfigurationTabGroup.java:74)
Back to TCF as per comment 9. The problem is missing Bundle.START_TRANSIENT argument in bundle.start() call. I'll commit a fix. Fixed. |
Build ID: CDT 8.0 (Indigo) / org.eclipse.tm.tcf_0.4.0.201106081058 I noticed that with CDT 8.0 installed, the Eclipse Workspace Selection Dialog did no longer show up. I know from previous experience that this can easily happen when a bundle accidentally sets the osgi.instance.location early, before the Workspace selection dialog has a chance to detect the instance location as empty. This can happen easily when a bundle calls Platform.getInstanceLocation() or Activator.getStateLocation() very early in the startup phase (ie before the ChooseWorkspaceDialog). So I performed a remote debug of my installation, with a breakpoint in BasicLocation#set() and I got this backtrace, which indicates that a Framework.resumeBundle() occurs on org.eclipse.tm.tcf.cdt.ui_0.4.0.201106081058 very early, and that bundle in turn activates the TCF Bundle, which in turn initializes the instance location early due to its TCFSecurityManager.getCertificatesDirectory(). I'm not sure what's a good fix... perhaps a startlevel can be used to defer loading of o.e.tm.tcf.cdt.ui ? Or initialization of the security manager can be deferred to a time when the instance location is already known? This is an annoing regression and should be fixed. Below is the stacktrace I found. I think from a workspace, this can be debugged by setting the workspace to "@noDefault" in the launch configuration. BasicLocation.set(URL, boolean, String) line: 143 [...] InternalPlatform.getStateLocation(Bundle, boolean) line: 612 Activator(Plugin).getStateLocation() line: 313 <!--- This is the problem TCFSecurityManager.getCertificatesDirectory() line: 48 TCFSecurityManager.createSSLContext() line: 61 Activator.start(BundleContext) line: 85 [This is org.eclipse.tm.tcf_0.4.0.201106081058] [...] DefaultClassLoader(ClassLoader).loadClass(String) line: not available Activator.start(BundleContext) line: 36 [This is org.eclipse.tm.tcf.cdt.ui_0.4.0.201106081058] [...] Framework.resumeBundle(AbstractBundle) line: 1130 StartLevelManager.resumeBundles(AbstractBundle[], boolean, int) line: 559 StartLevelManager.resumeBundles(AbstractBundle[], int) line: 544 StartLevelManager.incFWSL(int, AbstractBundle[]) line: 457 StartLevelManager.doSetStartLevel(int, FrameworkListener[]) line: 243 StartLevelManager.dispatchEvent(Object, Object, int, StartLevelEvent) line: 438 StartLevelManager.dispatchEvent(Object, Object, int, Object) line: 1 EventManager.dispatchEvent(Set, EventDispatcher, int, Object) line: 230 EventManager$EventThread.run() line: 340