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.
6.1, linux (editing | saving)* unresponsive completion close file try to open it again by Ctrl-click from another file and it is frozen
Created attachment 61365 [details] thread dump
Hm, the root problem here seems to be that read access to a document cannot be obtained (presumably because someone took a write/atomic lock and forgot to release it). Mila, would it be possible to print some logs if someone holds document (atomic) lock more than (say) 2 seconds?
This is going to be hard to track down.
Since we control the atomicLock() we should be able to provide at least something. I have the old tracking somewhere but I will probably try to improve it anyway. Of course a particularly problematic is matching atomic locks to atomic unlocks since just using a push/pop on a stack will not discover when a nested missing atomiUnlock() is a problem. Since lock()/unlock() pairs are typically inside a single method (hoping there are very few or possibly no exception) I think I could attempt to examine elements of Throwable.getStackTrace(). Then I could use a stack and the solution would be simple and exact. I will give it a try.
*** Issue 132997 has been marked as a duplicate of this issue. ***
Hanzi, please take a look at it. Thanks
Its hard to find fix in client code in this situation. There is no logging, any any king of logging is slow, in this case. Concept of atomicLock() atomicUnlock () methods is wrong, I think. There is correct replacement for these methods: BaseDocument.runAtomic (Runnable). So, I am deprecating these two methods, and I am adding some logging there - see diff.
Created attachment 65157 [details] Diff
Hanzi, you should assign this to apireviews if you want it reviewed. I also think we should wait for Mila to comment on this.
*** Issue 132983 has been marked as a duplicate of this issue. ***
fixed in 3299e8acbcc4