Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 126385 - New project wizard stuck when creating a project in mercurial repository
New project wizard stuck when creating a project in mercurial repository
Product: versioncontrol
Classification: Unclassified
Component: Mercurial
All All
: P1 (vote)
: 6.x
Assigned To: issues@versioncontrol
: 126323 126663 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2008-01-31 13:26 UTC by Jiri Skrivanek
Modified: 2008-02-12 14:43 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

Thread dump. (27.02 KB, text/plain)
2008-01-31 13:27 UTC, Jiri Skrivanek
Screen shot. (249.67 KB, image/gif)
2008-01-31 13:27 UTC, Jiri Skrivanek
messages.log with mercurial logging. (99.77 KB, text/plain)
2008-02-01 09:19 UTC, Jiri Skrivanek
proposed patch (4.06 KB, patch)
2008-02-01 11:57 UTC, Padraig Obriain
Details | Diff
additional patch (1.06 KB, patch)
2008-02-01 12:06 UTC, Padraig Obriain
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2008-01-31 13:26:16 UTC
New project wizard is locked when it tries to create a project in mercurial repository and other mercurial thread is
running. It breaks commit validation tests often since build 20080130-2221. To reproduce:

- run IDE with usedir in Hg repository (e.g. main/myuserdir - this case is common when you run UI tests)
- there should be "Changing..." task running in progress bar (I don't know what it is doing)
- immediatelly open new project wizard
- choose Ruby|Ruby Application and click Next
- select project location inside your userdir
- click Finish. The New Project wizard is never closed and the "Changing" task is never finished (see attached thread dump)

You can also reproduce it in tests:

cd main/ide.kit/test
ant -Dxtest.attribs=ruby

Product Version: NetBeans IDE Dev (Build 20080131071558)
Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19
System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
Userdir: D:\Development\hg\_main\aaauserdir
Comment 1 Jiri Skrivanek 2008-01-31 13:27:00 UTC
Created attachment 55835 [details]
Thread dump.
Comment 2 Jiri Skrivanek 2008-01-31 13:27:25 UTC
Created attachment 55836 [details]
Screen shot.
Comment 3 Martin Krauskopf 2008-01-31 13:51:59 UTC
Mercurial task has not finished for some reason. Not sure why. Reassigning.
Comment 4 Padraig Obriain 2008-01-31 14:37:15 UTC
I can reproduce this when I attempt to create Ruby project in main.
Comment 5 Padraig Obriain 2008-01-31 15:40:06 UTC
Looking at the thread dump I see a thread BLOCKED after call to Sharability.getSharability after call to 
FileStatusCache.refresh in fileChangedImpl in

Another thread is WAITING for the RequestProcessor being used by the4 previously mentioned thread in HgMoveImplementation.

My proposed fix will not call FileStatusCache.refresh in fileChangedImpl for files which Mercurial is ignoring.

This is a _GOOD_ thing to do in any case as it does not make sens to update the cache at this point for files which are
being ignored.

It has the added benefit of fixing this bug. 
Comment 6 Jiri Skrivanek 2008-01-31 16:53:38 UTC
I also wonder why mercurial plugin is doing something ("Changed..." task) when IDE is opened. There are no project
opened, only userdir is under mercurial repository.
Comment 7 Padraig Obriain 2008-02-01 09:10:28 UTC
My intended fix does not seem to address the root cause. I need to look further.
We seem to have our RequestProcessor thread hanging for some reason which prevents us using it
do to a move.

Does cancelling the "Changing" task help?

As to why we see "Changing ..." if one adds -J-Dorg.netbeans.modules.mercurial.level=100
to netbeans_default_options the output in messages.log may give us a clue as to what files
are being reported as changed.
Comment 8 Jiri Skrivanek 2008-02-01 09:18:55 UTC
> Does cancelling the "Changing" task help?

Actually there is at least 5 tasks queued and if you cancel one, another new appear. I will attach requested log.
Comment 9 Jiri Skrivanek 2008-02-01 09:19:28 UTC
Created attachment 55892 [details]
messages.log with mercurial logging.
Comment 10 Padraig Obriain 2008-02-01 10:41:12 UTC
I think that the cause of the problem is the waitFinished call in hgMoveImplementation. This seems to cause the lock
contention I see in the thread dump.

The thread in which hgMoveImplementation is called has locked a NamingFactory. Another thread which is waiting to
lock NamingFactory has locked a SynchronizedMap. The thread in which FileStatuscache.refresh is called is waiting to
lock the SynchronizedMap.

Removing the waitFinished call should allow the threads to proceed. The effect of this is the the move will not have
actually have been done when hgMoveImplementation has finished. The reason we must do the move in our RequestProcessor
is that we need to determine the status of the file being moved to determine how to move it.
Comment 11 Padraig Obriain 2008-02-01 11:36:49 UTC
*** Issue 126323 has been marked as a duplicate of this issue. ***
Comment 12 Padraig Obriain 2008-02-01 11:57:32 UTC
Created attachment 55903 [details]
proposed patch
Comment 13 Padraig Obriain 2008-02-01 12:06:25 UTC
Created attachment 55906 [details]
additional patch
Comment 14 Padraig Obriain 2008-02-01 12:06:58 UTC
changeset:   65473:2ad4620d4cdc
tag:         tip
date:        Fri Feb 01 11:50:03 2008 +0000
files:       mercurial/src/org/netbeans/modules/mercurial/MercurialInterceptor.j
ava mercurial/src/org/netbeans/modules/mercurial/util/
126385: Do not call waitFinished() in hgMoveImplementation. This fixes lock cont
126414: Check for ignored file when moving
Do not refresh cache for ignored file in FileChangedImpl

changeset:   65543:ad28fddc2ba0
tag:         tip
date:        Fri Feb 01 11:47:10 2008 +0000
files:       mercurial/src/org/netbeans/modules/mercurial/
Fix diagnostic.

Comment 15 Padraig Obriain 2008-02-06 07:52:17 UTC
*** Issue 126663 has been marked as a duplicate of this issue. ***
Comment 16 Jiri Skrivanek 2008-02-12 14:43:19 UTC

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo