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 34943 - Multiple commit freezes NB 3.5
Summary: Multiple commit freezes NB 3.5
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Petr Nejedly
URL:
Keywords: RANDOM, THREAD
: 36787 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-07-15 16:42 UTC by kovica
Modified: 2008-12-22 23:37 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Thread dump (15.32 KB, text/plain)
2003-07-15 16:42 UTC, kovica 		Details
The deadlock (4.19 KB, text/plain)
2003-10-31 10:23 UTC, _ pkuzel 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description kovica 2003-07-15 16:42:10 UTC 
I've tried commited multiple files into CVS
repository and the NB freezed.

Attached is thread dump.
Comment 1 kovica 2003-07-15 16:42:56 UTC 
Created attachment 10983 [details]
Thread dump
Comment 2 Jiri Kovalsky 2003-07-16 09:04:17 UTC 
I bet it's not reproducable, is it ?
Comment 3 kovica 2003-07-16 09:55:13 UTC 
Yes, you are right.
I'm not sure if the bug report is so lame or you already know about
this. :)
Comment 4 Jiri Kovalsky 2003-07-16 10:00:09 UTC 
Big brother is watching you !
No, I am joking. Deadlocks usually happen intermittently.
Comment 5 kovica 2003-07-16 14:27:17 UTC 
I was watching through thread dump and I can see (I hope I'm
interpretting this correclty) 
at org.openide.text.Line$Set.registerLine(Line.java:320)
        - locked <0x46404a10> (a java.util.WeakHashMap)
        at
org.openide.text.DocumentLine$Set.getCurrent(DocumentLine.java:756)
        at
org.netbeans.modules.tasklist.core.TLUtils.getLineByNumber(TLUtils.java:43)
        at
org.netbeans.modules.tasklist.suggestions.SuggestionManagerImpl.caretUpdate(SuggestionMa

so this is maybe taslklist's fault ?
I'm reassinging.

And I'm using NB 3.5.1 RC1.
Comment 6 Martin Entlicher 2003-07-21 12:46:15 UTC 
Javacvs is definitely not causing this deadlock. After checkout, the
committed files are refreshed, which caused the documents to be
updated. It *might* be a fault of org.openide.text.* package that it
does not provide the thread safety. Reassign to openide/text if this
is not a fault of tasklist module.
Comment 7 _ pkuzel 2003-10-31 10:23:28 UTC 
Created attachment 12027 [details]
The deadlock
Comment 8 _ pkuzel 2003-10-31 10:27:02 UTC 
registerLine() calls under lines-lock code that spawns (and wait for)
next thread that wants to grab the lines-lock.
Comment 9 Petr Nejedly 2003-11-27 09:25:52 UTC 
*** Issue 36787 has been marked as a duplicate of this issue. ***
Comment 10 Petr Nejedly 2003-11-27 09:27:45 UTC 
Mila's comments from the other issue:

Syncing RP is loading a doc but waits on "lines" while AWT holds
"lines" but waits on doc loading.

This problem exists in 3.5 and 3.5.1 and it will probably occur even
with the current openide.text in the trunk. The recent patch that I've
did will not solve this sort of problem.

There might be a solution to sync on CloneableEditorSupport.getLock()
instead of "lines" var in all the occurrences. As the
CES.openDocument() waits on CES.getLock() (i.e. it releases the lock)
the RP could proceed. But it's just an idea that would have to be tested.
Comment 11 Petr Nejedly 2004-01-09 16:27:34 UTC 
Let's fix it for 3.6
Comment 12 Petr Nejedly 2004-01-26 12:25:34 UTC 
Thanks to Yarda's fix of issue 37767, this deadlock can't occur
anymore, because before locking the lines lock, a document read lock
have to be acquired, which won't proceed until the document is fully
loaded (loading goes through document writeLock).
Comment 13 Marian Mirilovic 2004-02-26 17:04:06 UTC 
Ok, I am verifying , no response for long time and I hope it's already
fixed.
 Gregor if disagree reopen, thanks in advance .