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 - Hanging IDE after 'goto source'
Summary: Hanging IDE after 'goto source'
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jan Jancura
: 132983 132997 (view as bug list)
Depends on:
Reported: 2008-05-13 23:50 UTC by _ rkubacki
Modified: 2008-07-29 09:59 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

thread dump (25.55 KB, text/plain)
2008-05-13 23:51 UTC, _ rkubacki
Diff (5.74 KB, text/plain)
2008-07-21 17:55 UTC, Jan Jancura

Note You need to log in before you can comment on or make changes to this bug.
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]
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
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