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.
Symptoms: - IDE locks up - Repainting may or may not continue correctly - Wait cursor in all windows
Created attachment 10773 [details] Thread dump
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 "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.
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 suggest.
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: IDE Configuration / 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 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.
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 Timer Queue AWT-Event-Queue-0 AWT-Windows 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 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 SwingPropertyChangeSupport Still even when assuming these places there seem to be no deadlock conditions. 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.