Community
Participate
Working Groups
The stacjk trace below, perahps aggravated by irregular scheduling due to breakpoints in a nested EClipse demonstrates that the PDEPlugin can start on a worker thread resulting an Invalid Thread Access when starting preferences. Thread [Worker-9: Building workspace] (Suspended (breakpoint at line 4481 in SWT)) SWT.error(int) line: 4481 Display.error(int) line: 1185 Display.checkDevice() line: 737 Display.getHighContrast() line: 1819 ColorManager.initializeDefaults(IPreferenceStore) line: 50 PreferenceInitializer.initializeDefaultPreferences() line: 28 PreferenceServiceRegistryHelper$1.run() line: 301 SafeRunner.run(ISafeRunnable) line: 45 PreferenceServiceRegistryHelper.runInitializer(IConfigurationElement) line: 304 PreferenceServiceRegistryHelper.applyRuntimeDefaults(String, WeakReference<Object>) line: 134 PreferencesService.applyRuntimeDefaults(String, WeakReference<Object>) line: 375 DefaultPreferences.applyRuntimeDefaults() line: 225 DefaultPreferences.load() line: 279 DefaultPreferences(EclipsePreferences).create(EclipsePreferences, String, Object) line: 370 DefaultPreferences(EclipsePreferences).internalNode(String, boolean, Object) line: 623 DefaultPreferences(EclipsePreferences).node(String) line: 766 DefaultScope(AbstractScope).getNode(String) line: 41 DefaultScope.getNode(String) line: 77 PDEPreferencesManager.<init>(String) line: 37 PDEPlugin.getPreferenceManager() line: 69 TargetStatus.initializeTargetStatus() line: 188 PDEPlugin.start(BundleContext) line: 210 BundleContextImpl$3.run() line: 782 BundleContextImpl$3.run() line: 1 AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not available [native method] BundleContextImpl.startActivator(BundleActivator) line: 775 BundleContextImpl.start() line: 732 EquinoxBundle.startWorker0() line: 1005 EquinoxBundle$EquinoxModule.startWorker() line: 357 EquinoxBundle$EquinoxModule(Module).doStart(Module$StartOptions...) line: 588 EquinoxBundle$EquinoxModule(Module).start(Module$StartOptions...) line: 456 SecureAction.start(Module, Module$StartOptions...) line: 471 EclipseLazyStarter.postFindLocalClass(String, Class<?>, ClasspathManager) line: 117 ClasspathManager.findLocalClass(String) line: 557 EquinoxClassLoader(ModuleClassLoader).findLocalClass(String) line: 331 BundleLoader.findLocalClass(String) line: 395 SingleSourcePackage.loadClass(String) line: 39 BundleLoader.findClassInternal(String, boolean) line: 469 BundleLoader.findClass(String, boolean) line: 422 BundleLoader.findClass(String) line: 414 EquinoxClassLoader(ModuleClassLoader).loadClass(String, boolean) line: 153 EquinoxClassLoader(ClassLoader).loadClass(String) line: 357 Class<T>.getDeclaredConstructors0(boolean) line: not available [native method] Class<T>.privateGetDeclaredConstructors(boolean) line: 2671 Class<T>.getConstructor0(Class<?>[], int) line: 3075 Class<T>.getDeclaredConstructor(Class<?>...) line: 2178 EquinoxRegistryStrategy(RegistryStrategyOSGI).createExecutableExtension(RegistryContributor, String, String) line: 206 ExtensionRegistry.createExecutableExtension(RegistryContributor, String, String) line: 934 ConfigurationElement.createExecutableExtension(String) line: 246 ConfigurationElementHandle.createExecutableExtension(String) line: 63 JavaModelManager$CompilationParticipants$1.run() line: 466 SafeRunner.run(ISafeRunnable) line: 45 JavaModelManager$CompilationParticipants.getCompilationParticipants(IJavaProject) line: 459 JavaBuilder.initializeBuilder(int, boolean) line: 610 JavaBuilder.build(int, Map, IProgressMonitor) line: 176 BuildManager$2.run() line: 833 SafeRunner.run(ISafeRunnable) line: 45 BuildManager.basicBuild(int, IncrementalProjectBuilder, Map<String,String>, MultiStatus, IProgressMonitor) line: 220 BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, ICommand[], MultiStatus, IProgressMonitor) line: 263 BuildManager$1.run() line: 316 SafeRunner.run(ISafeRunnable) line: 45 BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, MultiStatus, IProgressMonitor) line: 319 BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor) line: 371 BuildManager.build(IBuildConfiguration[], IBuildConfiguration[], int, IProgressMonitor) line: 392 AutoBuildJob.doBuild(IProgressMonitor) line: 154 AutoBuildJob.run(IProgressMonitor) line: 244 Worker.run() line: 63
(In reply to Ed Willink from comment #0) > perahps aggravated by irregular scheduling No. I think it just needs a don't Build Automatically preference to suppress the early build. Then a late on-demand build occurs on the worker thread of a build-before-launch launch.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Cannot be stale until some committer triages it.
I see many cases of Display.getDefault inside pde.ui, which is not allowed. This can potentially cause issues in rare synchronization cases (e.g. holding a breakpoint on a crucial spot). The fix probably is to replace Display.getDefault with PlatformUI.getWorkbench().getDisplay() or even wrap it inside Platform.isWorbenchRunning.
(In reply to Wim Jongman from comment #4) > I see many cases of Display.getDefault inside pde.ui, which is not allowed. > > This can potentially cause issues in rare synchronization cases (e.g. > holding a breakpoint on a crucial spot). > > The fix probably is to replace Display.getDefault with > PlatformUI.getWorkbench().getDisplay() or even wrap it inside > Platform.isWorbenchRunning. Any chances of a patch?
(In reply to Vikas Chandra from comment #5) > (In reply to Wim Jongman from comment #4) > > Any chances of a patch? I think this only fails in lab circumstances and does not occur in the wild. Ed, can you describe how to make this fail?
See Description and Comment 1. Comment 4 clearly confirms that the PDE UI uses a bad coding practice and suggests a fix. If the bug is reproducible by code review then what more is needed?
(In reply to Ed Willink from comment #7) > See Description and Comment 1. > > Comment 4 clearly confirms that the PDE UI uses a bad coding practice and > suggests a fix. If the bug is reproducible by code review then what more is > needed? I already told you: a reproducible test case and users that actually see this error in the wild.
