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: | Reentrant JAR loading call fails due to I/O monitoring & GUI from MenuWarmUpTask | ||
---|---|---|---|
Product: | platform | Reporter: | Jan Lahoda <jlahoda> |
Component: | Module System | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jglick |
Priority: | P2 | Keywords: | THREAD |
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Two full thread dumps. |
The lock in NbBundle blocking EQ is just a distraction. The problem is that while loading a JAR, ZipFile.<init> causes some I/O monitoring magic (recently added by jtulach for checking external changes) to run, which in turn tries to load GUI stuff, which happens to need the exact same bundle from the same JAR which is not yet loaded. I think MenuWarmUpTask$NbWindowsAdapter$1HandleBridge.run should make calls to ProgressHandle asynchronously. (Preloading the label "Suspend" might work, but this still seems unsafe.) Or FileChangedManager.waitIOLoadLowerThan should post goingToSleep to a RequestProcessor. core-main#a3f486697542 - I am not sure if the fix makes it for 6.9 or not. Defensively setting the target milestone as Next. |
Created attachment 98954 [details] Two full thread dumps. [build from tip e57938878158 (from jet-main)] A "deadlock" happened to me, see attached full thread dumps.