Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 34539 - Possible deadlock in source editor, often manifests after Save All / compilation
Possible deadlock in source editor, often manifests after Save All / compilation
Product: editor
Classification: Unclassified
Component: -- Other --
PC Windows XP
: P2 (vote)
: 3.x
Assigned To: Dusan Balek
Depends on:
  Show dependency treegraph
Reported: 2003-06-23 17:39 UTC by bartholomew
Modified: 2007-11-05 13:44 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

Thread dump (10.97 KB, text/plain)
2003-06-23 17:40 UTC, bartholomew
Same thread dump as original but not wrapped (10.86 KB, text/plain)
2004-01-22 11:57 UTC, Miloslav Metelka

Note You need to log in before you can comment on or make changes to this bug.
Description bartholomew 2003-06-23 17:39:25 UTC

- IDE locks up
- Repainting may or may not continue correctly
- Wait cursor in all windows
Comment 1 bartholomew 2003-06-23 17:40:17 UTC
Created attachment 10773 [details]
Thread dump
Comment 2 Martin Roskanin 2003-06-27 10:16:55 UTC
I do not see a deadlock in thread dump. Anyway, thread OpenFile Server
looks very suspicious. Marian, what do you say? Haven't you met with
the similar issue in utilities module?
Comment 3 Marian Petras 2003-06-27 11:00:24 UTC
I do not see anything suspicious on the stack trace of thread
"OpenFile Server":
- it is runnable
- no thread is waiting for the locks acquired by this thread

The thread is is just waiting for data on a socket.
Comment 4 bartholomew 2003-06-27 11:23:23 UTC
Please forgive my naivety as I am unfamiliar with the 
internal workings of NetBeans.  I am using only local 
filesystems so why is this thread waiting on a socket?
Comment 5 Martin Roskanin 2003-06-27 12:17:52 UTC
Yes, Bart. This is very strange, why the socket connection is running.
Anyway, if you can reproduce the problem, more thread dumps would be
usefull. Could you please attach them? Also if the freeze happens take
one thread dump at start, other some time (minute) later. Thanks.
Comment 6 Miloslav Metelka 2003-06-27 12:22:06 UTC
Could you please try to disable utilities module (Named "User
Utilities" under Tools->Options->IDE Cfg->System->Modules) for a while
whether that will make any change to symptoms?
Comment 7 bartholomew 2003-06-27 12:23:28 UTC
OK, no problem.  It doesn't happen too often.  I had a 
similar thing with the RCs but didn't get any thread 
dumps.  Next time it happens I'll grab at least the two you 
Comment 8 bartholomew 2003-06-27 12:28:45 UTC
OK, I'll disable the User Utilities module when I've 
grabbed the thread dumps the next time it happens.
Comment 9 Miloslav Metelka 2003-06-27 12:41:05 UTC
If it only happens occasionally it's probably not a good idea to
disable utilities module because besides openfile server it AFAIK
contains filesystem search and other things. Anyway once you find out
that something you've used is no longer available you can turn the
utilities module back on.

IMHO once a thread of the JVM enters a native method (in our case it's it reports other threads
as waiting on monitor which is obviously not true e.g. in case of
SwingPropertyChangeSupport.firePropertyChange() there is apparently no
synchronization in the method declaration or in the method's body.

It's a question whether the JVM would finally leave the peekData()
call. I would bet that it would but there can be various network
related timeouts etc. Anyway I'm just guessing as I don't have full
JVM sources to see what the method actually does.
Comment 10 Marian Petras 2003-06-27 13:31:25 UTC
You can easily turn the Open File Server off.

1) Invoke the Options dialog (main menu: Tools -> Options).
2) In the dialog, select node:

     IDE Configuration
        / Server and External Tool Settings
           / Open File Server

3) Toggle its property "Running" to False.
Comment 11 Miloslav Metelka 2003-06-27 16:02:02 UTC
Thanks Marian. On Fridays I have problems to think reasonably.
Hopefully on Fridays only ;-)
Comment 12 Jesse Glick 2003-07-23 21:32:49 UTC
I seriously doubt the Open File Server thread or the utilities module
has anything to do with this at all. It is just waiting for socket
connections, as it does for everyone all the time, if the server is
running (which by default it is on Windows machines). You can ignore
that thread.

The deadlock is apparently between the AWT event thread, and the "Java
source parsing" RP thread. Given that the methods in the stack trace
don't directly show what is being synchronized on or where the
deadlock lies, it seems most likely that HotSpot has optimized out
some methods and so those stack frames are missing.

SwingPropertyChangeSupport.fPC *does* synchronize (on this) in the
other overload, which is probably inlined; maybe that is the lock
being acquired. However that does not look deadlock-prone to me (no
callbacks from the synch blocks).

DocumentContent.createBiasPosition similarly synchs indirectly through
MarkVector, for example; maybe this is related.
Comment 13 Miloslav Metelka 2004-01-22 11:57:46 UTC
Created attachment 13022 [details]
Same thread dump as original but not wrapped
Comment 14 Miloslav Metelka 2004-01-22 12:07:54 UTC
Honestly I do not see any apparent deadlock in the thread dump. There
are the following threads waiting on monitors:

Java Source Parsing
Timer Queue

I've tried to search for the places where the locks reported in the
thread dump are acquired but I do not have JDK sources here which will
be needed to search in the sun.* packages. It seems to me more like a
deadlock in JDK but we should make more detailed analysis.

Assigning to Dusan.

Bart is this still happening to you? If so could you please send us an
exact JDK version? Please send us output of "java -version". Thanks.
Comment 15 Miloslav Metelka 2004-02-04 13:21:55 UTC
I've searched for possible places where the real monitors are entered.
For Java source parsing thread the nearest place for monitor acquiring is
synchronized MultiMark insert(MultiMark mark) in MarkVector

TimerQueue thread is waiting on AppContext.get() - I've looked into
j2sdk sources and there is synchronization on "table" variable which
is java.util.HashMap

For AWT-Event-Queue-0 thread the nearest place for monitor acquiring
is line 253 with synchronizes(this) in
public void firePropertyChange(PropertyChangeEvent evt) in

Still even when assuming these places there seem to be no deadlock

Instead it looks to me like a spurious deadlock reported by JVM
problem - likely a similar problem like in the issue 37793.

Therefore I'm closing this as wontfix for now. Please reopen the issue
if it the problem reappears.

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