- IDE locks up
- Repainting may or may not continue correctly
- Wait cursor in all windows
Created attachment 10773 [details]
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?
I do not see anything suspicious on the stack trace of thread
- 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.
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?
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.
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?
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
OK, I'll disable the User Utilities module when I've
grabbed the thread dumps the next time it happens.
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
java.net.PlainDatagramSocketImpl.peekData()) 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.
You can easily turn the Open File Server off.
1) Invoke the Options dialog (main menu: Tools -> Options).
2) In the dialog, select node:
/ Server and External Tool Settings
/ Open File Server
3) Toggle its property "Running" to False.
Thanks Marian. On Fridays I have problems to think reasonably.
Hopefully on Fridays only ;-)
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
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.
Created attachment 13022 [details]
Same thread dump as original but not wrapped
Honestly I do not see any apparent deadlock in the thread dump. There
are the following threads waiting on monitors:
Java Source Parsing
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.
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
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.