This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I am seeing NB3.2build15 hang every time I attempt to invoke the parser database update tool on the JCE1.2.1 jar in the jre/lib/ext directory. The steps: 1. Mount the jce1_2_1.jar in the VM jre/lib/ext directory 2. Select the jar in the Explorer and Choose Tools->Update parser database This is resulting in a hung application every time. See the attached thread dump.
Created attachment 920 [details] Thread dump
Created attachment 921 [details] system/ide.log
It should be a problem of openide. Feel free to re-assign to editor if I am wrong.
Note that two threads are deadlocked holding both the app and the extension classloaders. Not sure what we are supposed to do about this.
Could CompileDataObject not call unknown code from its constructor => not call initCookies or at least isJavaBean?
It could, but I doubt that it would solve the real cause of this problem: sun.misc.Launcher$ExtClassLoader@1C44FB0/1C9A440: owner "Folder recognizer"(0xc48ac60) 1 entry Waiting to enter: "AWT-EventQueue-0" (0x71e95c8) sun.misc.Launcher$AppClassLoader@1C46708/1C9D358: owner "AWT-EventQueue-0" (0x71e95c8) 4 entries Waiting to enter: "Folder recognizer" (0xc48ac60) "OpenIDE Request Processor-0" (0x730afc0) java.lang.ClassLoader holds a lock on itself during its call to parent.loadClass(). Virtually any two calls to loadClass() with initialize=true could deadlock the VM this way.
BTW the problem is, that the JAR is (or seems to be) signed. So during class loading, the URLClassLoader (ExClassLoader instance) constructs some object instances - WHILE holding a lock - and those instances use another URLClassLoader (AppClassLoader). The AWT thread first tries AppClassLoader.loadClass() and acquires a lock on it, then the class loader delegates to the parent - ExClassLoader.
The deadlock is really between two JDK-provided class loaders. It can occur when some thread is trying to load signed class and another one is loading normal class at the same time. I've changed initialization of the CompiledDataObject as Yarda suggested - it will probably help, but it does not remove the real cause.
Merged to 3.2
[NB3.2.39] Verified If this bug still lives, please reopen.
Target milestone -> 3.2
Resolved for 3.3.x or earlier, no new info since then -> closing.