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.

Bug 46158 - Deadlock when opening the Mount component
Summary: Deadlock when opening the Mount component
Status: RESOLVED DUPLICATE of bug 46561
Alias: None
Product: java
Classification: Unclassified
Component: Javadoc (show other bugs)
Version: 4.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Jan Pokorsky
URL:
Keywords: THREAD
Depends on:
Blocks:
 
Reported: 2004-07-14 16:28 UTC by Jaroslav Tulach
Modified: 2004-08-13 12:11 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Thread dump (12.97 KB, text/plain)
2004-07-14 16:28 UTC, Jaroslav Tulach
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2004-07-14 16:28:11 UTC
I've got following deadlock when I executed the
nbbuild/build.xml with ant tryme and then opened
the Windows/Mount component.
Comment 1 Jaroslav Tulach 2004-07-14 16:28:40 UTC
Created attachment 16254 [details]
Thread dump
Comment 2 Jesse Glick 2004-07-14 18:10:15 UTC
Looks to be a bug in the javadoc module. Downgrading priority since it
is not known to occur except in the presence of this (experimental)
module, but it could occur in other situations.

Explanation of bug: JavadocRegistry registers a callback
(JR.pathsAdded) which can be (and is) called from within the scope of
ProjectManager.mutex()'s write lock. (Don't be fooled by the stack
trace - though inside readAccess here, the Runnable is called via
postWriteRequest.) This callback then attempts to acquire a new lock,
which is cannot guarantee is uncontended or will be released in a
bounded amount of time because it does not search for other new locks;
in particular, the new lock (JavadocRegistry itself) is also used by
JR.getDocRoots, which calls arbitrary foreign code
(JavadocForBinaryQuery) which can certainly acquire its own locks.
Therefore the callback is in error.
Comment 3 Jan Pokorsky 2004-08-09 11:49:57 UTC
It should be already fixed with issue #46561, #46876

*** This issue has been marked as a duplicate of 46561 ***