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.
Summary: | Reproducible deadlock on parser db update of lib/ext jar | ||
---|---|---|---|
Product: | java | Reporter: | Scott Stark <starksm> |
Component: | Unsupported | Assignee: | issues@java <issues> |
Status: | CLOSED FIXED | ||
Severity: | blocker | ||
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows ME/2000 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Thread dump
system/ide.log |
Description
Scott Stark
2001-03-30 03:38:06 UTC
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 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. |