Bugzilla – Full Text Bug Listing
| Summary: | Deadlock when core.runtime and equinox.app are started in parallel | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jens Borrmann <jens.borrmann> | ||||||
| Component: | Runtime | Assignee: | platform-runtime-inbox <platform-runtime-inbox> | ||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | tjwatson | ||||||
| Version: | 4.1 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 189933 [details]
The stacktrace of the deadlock copied from the debug view.
Created attachment 189934 [details]
Annotated and indented version of the stacktrace
Thanks for the annotated stacktrace. I don't think you should be able to reproduce this on 3.7 since PlatformLogWriter got moved into equinox.common. It appears that you have a non-singleton bundle that defines an extension or extension point? This is why EclipseBundleListener.getExtensionURL(Bundle, boolean) line: 128 is calling RuntimeLog.log which eventually calls out to PlatformLogWriter and this causes the out of order locking with the class loader. Unfortunately there is little we can do since the class loader lock is obtained and maintained by the VM. In Java 7 we will be able to support parallel capable class loaders which prevent the VM from locking at the class loader level. (In reply to comment #3) Thanks for your answer. > I don't think you should be able to > reproduce this on 3.7 since PlatformLogWriter got moved into equinox.common. Sounds like this could help in our case. What I cannot judge is wether this change (and other changes for 3.7) could cause similar problems in other situations. But fortunately that's not my job but yours ;-) > It appears that you have a non-singleton bundle that defines an extension or > extension point? Almost correct: We have an older version of aspectj in our target platform. The two respective bundles cause the following entries on the equinox console: !ENTRY org.eclipse.equinox.registry 2 0 2011-02-28 14:51:55.496 !MESSAGE The extensions and extension-points from the bundle "org.aspectj.weaver" are ignored. The bundle is not marked as singleton. !ENTRY org.eclipse.equinox.registry 2 0 2011-02-28 14:51:56.808 !MESSAGE The extensions and extension-points from the bundle "org.aspectj.runtime" are ignored. The bundle is not marked as singleton. In both cases the plugin.xml does not contain any extensions or extension points, but just an empty plugin element. So there is no real need for the warning. But I suppose there is no efficient way to find out that no warning would have to be logged. If this would be possible I would be very happy to be able to get rid of this warning. > > Unfortunately there is little we can do since the class loader lock is obtained > and maintained by the VM. In Java 7 we will be able to support parallel > capable class loaders which prevent the VM from locking at the class loader > level. Bad for us, as some of our customers are still using Java 5. 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. Since this bug was opened we have implemented parallel class loaders and require Java 7+ |
Build Identifier: 20100917-0705 We experience deadlocks when the bundles a) org.eclipse.core.runtime b) org.eclipse.equinox.app are started in parallel. In our case The parallel start is caused by one of our infrastructure bundles. The activator of our bundle starts a thread that executes accesses class Platform. This triggers lazy loading for org.eclipse.core.runtime. In the start level event dispatcher thread has begun starting org.eclipse.equinox.app. Those two threads block one another. I will attach both the stacktrace of the two relevant threads copied raw from the Debug View and the same stacktrace annotated with my findings while analyzing the situation. Reproducible: Sometimes Steps to Reproduce: 1. Create a situation in which the activators of eclipse.core.runtime eclipse.core.runtime and equinox.app are accessed simultaneously. (e.g. use the following code in the activator of a bundle that is started before any of those bundles: public void start(final BundleContext context) throws Exception { new Thread() { @Override public void run() { boolean result = Platform.isRunning(); }.start(); } This code triggers a lazy activation of core.runtime. In this case you have to make sure that equinox.app is started before core.runtime is started. 2. Set breakpoints in the activator of core.runtime and equinox.app. 3. Start the application and wait until both breakpoints are hit in parallel. 4. Set a breakpoint in the third line of PlatformLogWriter.getLog() (which will stop execution before loading class CoreException) and let the thread starting equinox.app hit this breakpoint. 5. Set a method entry breakpoint for ClasspathManager.findLocalClass_LockClassLoader and let the thread starting core.runtime hit this breakpoint. 6. Try to let both threads resume their work - they won't do it: Deadlock!