Bugzilla – Full Text Bug Listing
| Summary: | deadlock loading classes while activating bundles | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Jeff McAffer <jeffmcaffer> | ||||
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | irbull, pwebster, slewis, tjwatson | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Jeff McAffer
This is very much related to bug212262 and could be considered a duplicate. Running on Java SE 7 should fix it. You could try running with the following configuration option on Java SE 6 or 5: osgi.classloader.type=parallel If you are running on the Sun/Oracle VM <=6 then you must also run with the following VM options: -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass One thing that concerns me about the "main" stack track is that we are starting bundles in the "main" thread while in the middle of doing a ClassLoader.defineClass call. It appears the bundle associated with the class loader performing the ClassLoader.defineClass call is active since we do not push it onto the stack of bundles to be activated after successful class definition. This is behaving as specified. One thing we could consider doing is delaying the lazy starts until after the successful definition of the initiating class. Currently we delay until after the first "trigger" class is defined which may happen before returning from the initiating class definition. This would allow us to release at least one of the class loader locks before starting the lazy start bundles involved in the class definition call. I am reluctant to make that kind of change in behavior because of the change in start timing this would introduce. (In reply to comment #1) > This is very much related to bug212262 and could be considered a duplicate. > Running on Java SE 7 should fix it. You could try running with the following > configuration option on Java SE 6 or 5: > > osgi.classloader.type=parallel Sorry to have mislead you! This option is set to parallel by default and really only takes effect if running on Java 7. On pre-java7 you need the following set to prevent the class loader level lock: osgi.classloader.lock=classname > > If you are running on the Sun/Oracle VM <=6 then you must also run with the > following VM options: > > -XX:+UnlockDiagnosticVMOptions > -XX:+UnsyncloadClass > These options don't make any difference. Deadlock still occurs.
After talking with Tom some, it turns out that on Java <= 6 the parallel option in config.ini is not the thing to try. Rather is should be
osgi.classloader.lock=classname
the eclipse.ini (vm) arguments are still needed.
Will try this and report progress...
Note also that I entered bug 344727 against the UI to see about changing the way they do the WorkbenchPlugin bundle listening. While what they are doing "should" work, it clearly does not in certain situations of stock install.
Created attachment 194983 [details]
deadlock with lock classname
The deadlock is still happening even with classname locking.
*** Bug 352654 has been marked as a duplicate of this bug. *** 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. Things have changed much since this was opened. Closing as worksforme. |