all news
RSS feedTicket #122 (closed defect: fixed)
OTDT deadlocks on Sun JVM
| Reported by: | stephan | Owned by: | |
|---|---|---|---|
| Priority: | critical | Milestone: | OTDT_1.2.1 |
| Component: | third-party | Version: | 1.2.0pre |
| Keywords: | Cc: |
Description
Due to the problem described in Eclipse bug 121737 we were using the directive osgi.classloader.singleThreadLoads=true as a workaround.
Bugs Eclipse bug 227587, Eclipse bug 221329 and Eclipse bug 212262 discuss why this introduces another potential deadlock.
The root cause of this deadlock is the #1 most voted bug at Sun's Java site:
(see also http://bugs.sun.com/bugdatabase/top25_bugs.do).
I was lately seeing this reproduceably as a deadlock between two threads trying to use a ProgressManager where ProgressManager$1.updateFor was trying to load interface IJobChangeEvent, both threads locking on the same classloader. It appears that releasing (with wait) a lock that has been acquired from the native code of the VM is not possible! (That's what BundleLoader.lock() is trying by saying loader.wait()). Thus the workaround from Eclipse bug 121737 is more or less useless.
proposed current workarounds
- Avoid using the Sun JVM (they had time since April 2002 to fix this issue !!)
- If you need to use the Sun JVM, whenever a deadlock occurs you may try toggling the switch osgi.classloader.singleThreadLoads (true/false) in your eclipse/configuration/config.ini. It may help, because it switches between two slightly different potential deadlocks and chances are that only one of these potential deadlocks applies at a time. I know that this is neither convenient nor safe, but neither us nor the Equinox developers can actually do anything about this!
