Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 369917 - Deadlock in JavaReconciler while trying to lock DefaultClassLoader
Summary: Deadlock in JavaReconciler while trying to lock DefaultClassLoader
Status: CLOSED DUPLICATE of bug 212262
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.8.0 Juno   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: equinox.framework-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-27 06:49 EST by Matthias Schmidt CLA
Modified: 2012-01-31 08:47 EST (History)
3 users (show)

See Also:

Attachments
Stacktrace of deadlock from JDK 1.7.0-b147 (44.04 KB, text/plain)
2012-01-27 06:51 EST, Matthias Schmidt CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Schmidt CLA 2012-01-27 06:49:03 EST 
Build Identifier: Indigo Service Release 1, Build id: 20110916-0149

Every now and then, when I'm clicking in the editor pane of a java file inside a maven project eclipse deadlocks. The deadlock got detected by the JVM deadlock detection facility. Find a full stacktrace attached.

Reproducible: Sometimes

Steps to Reproduce:
Sorry guys, this happens every now and then (see above)
Comment 1 Matthias Schmidt CLA 2012-01-27 06:51:01 EST 
Created attachment 210174 [details]
Stacktrace of deadlock from JDK 1.7.0-b147
Comment 2 Dani Megert CLA 2012-01-30 08:26:50 EST 
Looks like a dup of bug 344030.
Comment 3 Thomas Watson CLA 2012-01-30 09:02:33 EST 
(In reply to comment #1)
> Created attachment 210174 [details]
> Stacktrace of deadlock from JDK 1.7.0-b147

Are you certain this is a Java 7 VM that you used?

> Full thread dump Java HotSpot(TM) Client VM (17.0-b17 mixed mode):
Some googling of 17.0-b17 indicates this is Java 6.

> at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:477)

The use of findLocalClass_LockClassLoader also indicates that this is Java 6 or earlier.

This seems a duplicate of bug212262 which can really only be fixed by the use of Java 7 and the utilization of the ClassLoader#registerAsParallelCapable method.
Comment 4 Matthias Schmidt CLA 2012-01-31 05:10:12 EST 
Sorry guys, my fault. Sure it is JDK6:

java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)
Comment 5 Thomas Watson CLA 2012-01-31 08:47:11 EST 
(In reply to comment #4)
> Sorry guys, my fault. Sure it is JDK6:
> 
> java version "1.6.0_21"
> Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
> Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)

Thanks for clarifying.  I am going to duplicate this to bug212262.  Unfortunately there is nothing we can do to avoid this kind of deadlock with out help from the Java 7 VM.  We have tried many times to no avail.

*** This bug has been marked as a duplicate of bug 212262 ***