Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 38582 - Deadlock during start of the IDE
Deadlock during start of the IDE
Product: serverplugins
Classification: Unclassified
Component: Infrastructure
PC Linux
: P3 (vote)
: 3.x
Assigned To: issues@serverplugins
Depends on:
  Show dependency treegraph
Reported: 2004-01-09 16:31 UTC by Petr Pisl
Modified: 2004-01-19 10:36 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

The deadlock is attached (13.24 KB, text/plain)
2004-01-09 16:32 UTC, Petr Pisl

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Pisl 2004-01-09 16:31:45 UTC
1) Go to  the Runtime tab->Server Registry->Tomcat
Server Instances -> http://localhost:8080/ node.
2)Shutdown the ide

3)Start the ide again.

It didn't freeze always.
Comment 1 Petr Pisl 2004-01-09 16:32:35 UTC
Created attachment 12808 [details]
The deadlock is attached
Comment 2 Pavel Buzek 2004-01-15 06:44:43 UTC
I do not see tomcat in any thread.
Comment 3 Nam Nguyen 2004-01-15 17:56:27 UTC
I could not reproduce this on Windows XP.  Maybe platform specific?
Comment 4 Petr Jiricka 2004-01-15 18:36:54 UTC
The stack trace seems to show that j2eeserver does nothing wrong -
could this be caused by openide/nodes?
Comment 5 Petr Pisl 2004-01-16 07:29:14 UTC
The code was changed in the last week. I'm not able to reproduce it as
well now. So we can close the bug.
Comment 6 Petr Nejedly 2004-01-16 12:08:51 UTC
The problem is in the j2ee ServerNode, which, when asked for a subnode
(under the Children.MUTEX.readAccess()) tries to reenter the mutex in
writeAccess (mutex upgrade), which is forbidden and deadlock prone (if
two threads try to upgrade , they'll surely deadlock). Pity the Mutex
doesn't correctly throw IllegalState (but it tries to, in some code

The important part of trace:
at oou.Mutex$Privileged.enterWriteAccess(1200) - ask writeAccess
at oon.Node.setChildren(353)
at j2ee.diu.FilterXNode.<init>(49)
at j2ee.diu.InstanceTargetXNode.<init>(47)
at j2ee.diu.InstanceTargetXNode.<init>(43)
at j2ee.diu.RegistryNodeProvider.createInstanceTargetNode(76)
at j2ee.diu.ServerNode$PluginChildren.createNodes(99)
at oon.Children$Keys$KE.nodes(1987)
at oon.ChildrenArray.nodesFor(109)
at oon.Children$Info.nodes(1083)
at oon.Children.justComputeNodes(589)
at oon.ChildrenArray.nodes(54)
at oon.Children.getNodes(325) - holds readAccess()
Comment 7 Petr Nejedly 2004-01-16 14:42:56 UTC
Btw: see issue 10778
Comment 8 Petr Jiricka 2004-01-16 17:14:28 UTC
Petr N., thanks for explanation, although I still don't understand the
issue exactly. ServerNode does not use the Children.MUTEX class at
all. Who exactly acquires the read lock?
Comment 9 Petr Nejedly 2004-01-16 17:55:01 UTC
Inside Children.getNodes, the Children.MUTEX is read-locked
(it is not visible in the thread dump, because Children internally
uses Mutex.Privileged).
Look at Children around line 325
ServerNode is called already under readLock (generally,
Children.Keys.createNodes(Object keyFor) is always called under 
Children.MUTEX's readLock.

The node created by the ServerNode.PluginChildren calls setChildren
from inside of its constructor, which is the problem, as setChildren
needs writeAccess.
If you can't resolve the children type before calling
superconstructor, you can wrap the setChildren with
But looking at the FilterXNode source, it would be enough to rewrite
the constructor to:
super(extendsChildren ? new XChildren(xnode) : original);
Comment 10 Nam Nguyen 2004-01-16 18:17:20 UTC
Petr N., thanks for the analysis and suggestion.  Eventhough I could
not reproduce the problem to say for sure whether its fixed, the
suggested change make sense so I will do it.
Comment 11 Nam Nguyen 2004-01-17 02:18:58 UTC
I changed code so to avoid invoking setChildren in the constructor of
Comment 12 Petr Jiricka 2004-01-19 10:36:51 UTC
Petr N., thanks for the thorough analysis and suggestions. I think it
would be useful to document in the Javadoc of
Children.Keys.createNodes(Object keyFor), that this method is called
under read lock. Without this, module writers have no way to find out
that they are doing something wrong. Thanks.

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