Bugzilla – Full Text Bug Listing
| Summary: | Deadlock on startup using DefaultClassLoader/StartupClassLoader locks | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Andrey Loskutov <loskutov> | ||||
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> | ||||
| Status: | CLOSED NOT_ECLIPSE | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | jamesblackburn+eclipse, Konstantin.Scheglov, tjwatson | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Andrey Loskutov
It is difficult to tell what the deadlock is without the stacks from the two deadlocked threads. It appears that this is another case where the VM locks the classloader and we are getting into a deadlock because of it. The thing I don't understand is why we need to obtain a bundle's class loader lock (on DefaultClassLoader) while loading classes with the StartupClassLoader. The StartupClassLoader is used to load the framework and the framework classes cannot have dependencies on classes loaded from a bundle class loader. Something else must be going on but it is impossible to tell at this point. Created attachment 179866 [details]
backtrace
This just occurred to me.
Using Sun JDK 1.6.0_16 main deadlocked with Worker-2 between the Main$StartupClassLoader and DefaultClassLoader locks.
Backtrace attached.
(In reply to comment #2) > Created an attachment (id=179866) [details] > backtrace > > This just occurred to me. > > Using Sun JDK 1.6.0_16 main deadlocked with Worker-2 between the > Main$StartupClassLoader and DefaultClassLoader locks. > > Backtrace attached. Thanks James, any idea what DesignerPlugin is? or why it appears they have installed a security manager. It looks like this is what is causing the deadlock in this case. The security manager for DesignerPlugin looks to be getting used while trying to load classes for the framework which causes additional classes to need to be loaded from the DesignerPlugin. I just noticed james is not cc'ed on the bug. James please see comment 3. (In reply to comment #3) > any idea what DesignerPlugin is? I guess this is com.instantiations.designer.core.DesignerPlugin from WindowBuilder from http://code.google.com/webtoolkit/tools/wbpro/index.html I have it recently installed on both machines, so this could be the initial root cause for my issues. (In reply to comment #5) > I have it recently installed on both machines, so this could be the initial > root cause for my issues. Same here! Until Java 7 is available and we can take advantage of parallel class loaders I am not sure what we can do about this in eclipse. Unfortunately the VM locks the startup class loader natively and we cannot really get around that. I suggest an issue be opened against WindowBuilder. I think the combination of installing a security manager and being an early startup plugin causes this deadlock to show up. If they must do both in WindowBuilder then one possible work around is for them to eagerly load the complete implementation of their security manager before setting it as the security manager of the VM. This way when it gets used to do security checks we don't need to load additional classes for the security manager while loading framework implementation classes. (In reply to comment #7) > I suggest an issue be opened against WindowBuilder. I did this, but have no idea if it was successful or not, as the bug submission can only be performed from their own plugin. There seems to be neither publicly accessible tracker nor email confirmation for the bug submission. So I can't put here any pointer to their bug tracker :-( I just want to confirm that as developer of WindowBuilder I've read this thread now and will try to fix problem. We use SecurityManager to prevent user code from executing exit(). We saw couple examples of this in user code and during using JFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) too. I will try to move installing SecurityManager to the time when we are going to parse and execute source. (In reply to comment #9) > I just want to confirm that as developer of WindowBuilder I've read this thread > now and will try to fix problem. Thanks Konstantin. It would be good if there were a public bug tracker for this tool as firing bug reports into the ether doesn't gives no positive feedback. Now we will install SecurityManager just before parsing, not during Bundle start. This change will be included into next public build. I am going to close this as not eclipse. Thanks all. |