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.

Bug 135004

Summary: Hanging IDE after 'goto source'
Product: editor Reporter: _ rkubacki <rkubacki>
Component: -- Other --Assignee: Jan Jancura <jjancura>
Status: RESOLVED FIXED    
Severity: blocker CC: mfukala
Priority: P2 Keywords: API_REVIEW_FAST, RANDOM
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Attachments: thread dump
Diff

Description _ rkubacki 2008-05-13 23:50:15 UTC 
6.1, linux

(editing | saving)*
unresponsive completion
close file
try to open it again by Ctrl-click from another file and it is frozen
Comment 1 _ rkubacki 2008-05-13 23:51:06 UTC 
Created attachment 61365 [details]
thread dump
Comment 2 Jan Lahoda 2008-05-14 13:59:55 UTC 
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?
Comment 3 Vitezslav Stejskal 2008-05-19 09:10:53 UTC 
This is going to be hard to track down.
Comment 4 Miloslav Metelka 2008-06-17 16:12:51 UTC 
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.
Comment 5 Jan Lahoda 2008-06-23 14:52:17 UTC 
*** Issue 132997 has been marked as a duplicate of this issue. ***
Comment 6 Jan Becicka 2008-07-17 08:27:30 UTC 
Hanzi, please take a look at it. Thanks
Comment 7 Jan Jancura 2008-07-21 17:54:55 UTC 
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.
Comment 8 Jan Jancura 2008-07-21 17:55:59 UTC 
Created attachment 65157 [details]
Diff
Comment 9 Vitezslav Stejskal 2008-07-23 10:49:50 UTC 
Hanzi, you should assign this to apireviews if you want it reviewed. I also think we should wait for Mila to comment on
this.
Comment 10 Jan Jancura 2008-07-23 14:24:36 UTC 
*** Issue 132983 has been marked as a duplicate of this issue. ***
Comment 11 Jan Jancura 2008-07-29 09:59:29 UTC 
fixed in 3299e8acbcc4