Bug 38582 - Deadlock during start of the IDE
Deadlock during start of the IDE
Status: RESOLVED FIXED
Product: serverplugins
Classification: Unclassified
Component: Infrastructure
3.x
PC Linux
: P3 (vote)
: 3.x
Assigned To: issues@serverplugins
issues@serverplugins
: THREAD
Depends on:
Blocks:
  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
:


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

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
Reproduce:
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
paths).

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
Mutex.postWriteAccess().
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
InstanceTargetXNode.
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. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo