Community
Participate
Working Groups
While loading class "org.eclipse.cdt.debug.internal.ui.pinclone.PinCloneUtils", thread "Thread[main,6,main]" timed out waiting (5000ms) for thread "Thread[Worker-2,5,main]" to finish starting bundle "org.eclipse.cdt.debug.ui_7.1.0.qualifier [39]". To avoid deadlock, thread "Thread[main,6,main]" is proceeding but "org.eclipse.cdt.debug.internal.ui.pinclone.PinCloneUtils" may not be fully initialized. Root exception: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1075) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:285) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:268) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:476) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.eclipse.cdt.debug.internal.ui.pinclone.ViewIDCounterManager$1.runInUIThread(ViewIDCounterManager.java:79) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95) [...] This is a known problem with the Sun/Oracle JVM during startup when one thread is activating a bundle and another thread tries to load classes from that bundle. See e.g. bug 36358, bug 86713 and bug 209920. The usual solution is to schedule all background jobs/threads at the very end of the start() method in the Activator.
Awesome, Patrick and I were just looking into that. Toni, how did you see this problem? We saw it when trying to run the DSF-GDB JUnit tests. See bug 334650.
(In reply to comment #1) > Awesome, Patrick and I were just looking into that. > > Toni, how did you see this problem? We saw it when trying to run the DSF-GDB > JUnit tests. See bug 334650. Nice coincidence. I saw it during normal startup from the workspace, but only once so far. It depends on the timing and which views are open, I'd guess.
When I launch into the Debug perspective and the Breakpoints view is open with a few C/C++ Breakpoints and no C/C++ Editor, I can reproduce it about every other time. At least this activates the cdt.debug.ui on a worker thread instead of the UI thread.
Created attachment 187008 [details] fix Toni, Marc, can you test this patch when you have a chance? Thanks.
(In reply to comment #4) > Created attachment 187008 [details] > fix > > Toni, Marc, can you test this patch when you have a chance? Thanks. Thanks Patrick, I did not try your patch, but I assume it would work. I think the synchronized (fInitialized) is problematic, though, because fInitialized changes. I have a patch ready for CDebugUIPlugin which leaves ViewIDCounterManager unchanged and also makes sure all other background initialization is done safely.
Created attachment 187012 [details] Fix #2 I'd suggest this solution.
I was thinking of doing the same, but try to minimized the number of changes. I have committed your fix to HEAD. Thanks for the patch.
*** cdt cvs genie on behalf of pchuong *** Bug 334651 - Deadlock reported during startup of cdt.debug.ui [*] CDebugUIPlugin.java 1.72 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/ui/CDebugUIPlugin.java?root=Tools_Project&r1=1.71&r2=1.72
