Bug 186107 - Reentrant JAR loading call fails due to I/O monitoring & GUI from MenuWarmUpTask
Reentrant JAR loading call fails due to I/O monitoring & GUI from MenuWarmUpTask
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Module System
6.x
PC Linux
: P2 (vote)
: 7.0
Assigned To: Jaroslav Tulach
issues@platform
: THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-13 14:00 UTC by Jan Lahoda
Modified: 2010-05-18 06:57 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Two full thread dumps. (57.59 KB, text/plain)
2010-05-13 14:00 UTC, Jan Lahoda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Lahoda 2010-05-13 14:00:55 UTC
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.
Comment 1 Jesse Glick 2010-05-13 15:36:56 UTC
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.
Comment 2 Jaroslav Tulach 2010-05-18 06:57:00 UTC
core-main#a3f486697542 - I am not sure if the fix makes it for 6.9 or not. Defensively setting the target milestone as Next.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo