ShareSource Site »
Projects » visualhg »
visualhgBug Tracker
Actions » View tickets | Report a bug
I have never seen this problem, but I will have a look at it.
For your information, the plugin asks for filestatus after on filechanges. This is triggered by a filesystem directory watcher. Everything is running in the background with a separate thread and low priority. So the status update do not hinder user interactions and do not slow down the studio performance. A log is not available, but a debug trace.
If you want to help to find out what happens, please do the following:
1 get the VisualHG source code
2 install VS SDK 2008
3 load VisualHG and start the debugger - this will load the HIVE (VisualStudio itself) as application and activate the plugin in the HIVE
4 load your project into the HIVE
5 start compiling your project in the HIVE
6 mail me a patch with with your fixes, or a detailed description
to VisualHG@Live.de
Regards
Bernd
Comment by: DM | Posted: Tuesday, 16 June 2009, 05:16AM (16/06/2009)
I did this now, below you can find a callstack.
The problem occurs with all of my projects, the bigger they are the more frequent it appears.
As I can see, "dirty files" are checked against the hg-database (files in /debug/, /obj/, ...) - why? They are not in the hg-database...
When compiling, VS of course deletes the files and recreates them, they are locked by VS - I'm pretty sure that this is the reason for the problem:
the plugin tries a "status -A" of about 90 files and is waiting in line 58 of HGLib.Hg.cs:
while ((str = process.StandardOutput.ReadLine()) != null).
the loop waits endlessly because the ReadLine() never returns.
I hope this information will help.
Best regards,
Dietmar
CallStack:
[Managed to Native Transition]
mscorlib.dll!System.IO.FileStream.ReadFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle handle, byte[] bytes, int offset, int count, System.Threading.NativeOverlapped* overlapped, out int hr = 0) + 0x87 bytes
mscorlib.dll!System.IO.FileStream.ReadCore(byte[] buffer, int offset, int count) + 0xb3 bytes
mscorlib.dll!System.IO.FileStream.Read(byte[] array, int offset, int count) + 0xc9 bytes
mscorlib.dll!System.IO.StreamReader.ReadBuffer() + 0x3b bytes
mscorlib.dll!System.IO.StreamReader.ReadLine() + 0x13c bytes
> HGLib.dll!HGLib.HG.InvokeCommand(string workingDirectory = "D:\prj\xxx", string arguments, out System.Collections.Generic.List<string> resultList = Count = Cannot evaluate expression because a native frame is on top of the call stack.) Line 57 + 0x15 bytes C#
HGLib.dll!HGLib.HG.QueryFileStatus(string[] fileList = {string[90]}, out System.Collections.Generic.Dictionary<string,char> fileStatusDictionary = Count = Cannot evaluate expression because a native frame is on top of the call stack.) Line 289 + 0x32 bytes C#
HGLib.dll!HGLib.HGStatus.UpdateDirtyFilesStatus() Line 576 + 0x1e bytes C#
HGLib.dll!HGLib.HGStatus.DirectoryStatusCheckerProc(object stateInfo = {System.Threading.AutoResetEvent}) Line 465 + 0x8 bytes C#
mscorlib.dll!System.Threading._TimerCallback.TimerCallback_Context(object state) + 0x2f bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6f bytes
mscorlib.dll!System.Threading._TimerCallback.PerformTimerCallback(object state) + 0x6b bytes
Comment by: Bernd Schrader | Posted: Saturday, 27 June 2009, 01:33PM (27/06/2009)
Hi DM,
please get the latest code and confirm if the following fix works for you.
Bernd
------
Removed not absolute needed file-created event handler from the DirectoryWatcher
to avoid testing of compiler generated intermediate files against the HG repo.
This should solve the problem of #340.
To avoid testing of intermediate compiler files by HG, place an entry
into the .hgignore file e.G.
syntax: regexp
bin/Debug
bin/Release
Comment by: Bernd Schrader | Posted: Saturday, 27 June 2009, 01:40PM (27/06/2009)
{{{
As I can see, "dirty files" are checked against the hg-database (files in /debug/, /obj/, ...) - why? They are not in the hg-database...
}}
This is to find out that these files are 'not versioned'.
Comment by: DM | Posted: Tuesday, 07 July 2009, 08:11AM (07/07/2009)
I got a new version of TortoiseHG now, the problem didn't even occur with VisualHG 1.0.5.
About the 'dirty files': My understanding of the plugin is that it shows the status of all files in the project and provides basic control of the mercurial database. In my opinion it should be enough to check all files which are in the project/solution?
Just an idea, the plugin works great now!
Comment by: DM | Posted: Tuesday, 07 July 2009, 08:13AM (07/07/2009)
I meant, it didn't appear with TortoiseHG 0.8 and VisualHG 1.0.5.
With TortoiseHG 0.7.x and VisualHG 1.0.5 it happened. Maybe the "status -a" is non-blocking now...
Comment by: Bernd Schrader | Posted: Wednesday, 08 July 2009, 05:46PM (08/07/2009)
Yes, you're right, it should be enough to check only files of the projects.
But I found out with my 'sonny' solution with about 7000 files (cpp) in 50 projects
this is the most stable and also well performing way to track all these states.
Thank you for your posting.
![[^]](/i/16x16/places/user-home.png)
![[_]](/i/16x16/actions/document-properties.png)
![[!]](/i/16x16/apps/kbugbuster.png)
Bug #340 [CLOSED]
Reason: Fixed
| Vital Bug Details | |
|---|---|
| Summery: Sometimes the plugin stops VS2008(SP1) from responding. | |
| Severity: Low | |
| Status: | Priority: Low |
| Assigned to: Nobody | Percent Complete: 100% |
| Bug Reporter | |
| Reported by: Anonymous ( on Thursday, 28 May 2009, 07:09AM (28/05/2009) ) | |
| Bug Details | |
| Sometimes the plugin stops VS2008(SP1) from responding, this happens during build (about 1 of 10 builds).
When I kill the subprocess hg.exe, the build continues correcly. I think the plugin asks for some filestatus continously and sometimes hg wants a user interaction which won't come - when this happens, VS is waiting until the action is done. Is there a way to view a logfile to see which actions VisualHG takes during build? I'm using VisualHG 1.0.5 and TortoiseHG 0.7.4, it was the same with VHG 1.0.3 and THG 0.7.3. |
|
| View History » | |
Comments
Comment by: Bernd Schrader | Posted: Saturday, 30 May 2009, 07:37AM (30/05/2009)I have never seen this problem, but I will have a look at it.
For your information, the plugin asks for filestatus after on filechanges. This is triggered by a filesystem directory watcher. Everything is running in the background with a separate thread and low priority. So the status update do not hinder user interactions and do not slow down the studio performance. A log is not available, but a debug trace.
If you want to help to find out what happens, please do the following:
1 get the VisualHG source code
2 install VS SDK 2008
3 load VisualHG and start the debugger - this will load the HIVE (VisualStudio itself) as application and activate the plugin in the HIVE
4 load your project into the HIVE
5 start compiling your project in the HIVE
6 mail me a patch with with your fixes, or a detailed description
to VisualHG@Live.de
Regards
Bernd
Comment by: DM | Posted: Tuesday, 16 June 2009, 05:16AM (16/06/2009)
I did this now, below you can find a callstack.
The problem occurs with all of my projects, the bigger they are the more frequent it appears.
As I can see, "dirty files" are checked against the hg-database (files in /debug/, /obj/, ...) - why? They are not in the hg-database...
When compiling, VS of course deletes the files and recreates them, they are locked by VS - I'm pretty sure that this is the reason for the problem:
the plugin tries a "status -A" of about 90 files and is waiting in line 58 of HGLib.Hg.cs:
while ((str = process.StandardOutput.ReadLine()) != null).
the loop waits endlessly because the ReadLine() never returns.
I hope this information will help.
Best regards,
Dietmar
CallStack:
[Managed to Native Transition]
mscorlib.dll!System.IO.FileStream.ReadFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle handle, byte[] bytes, int offset, int count, System.Threading.NativeOverlapped* overlapped, out int hr = 0) + 0x87 bytes
mscorlib.dll!System.IO.FileStream.ReadCore(byte[] buffer, int offset, int count) + 0xb3 bytes
mscorlib.dll!System.IO.FileStream.Read(byte[] array, int offset, int count) + 0xc9 bytes
mscorlib.dll!System.IO.StreamReader.ReadBuffer() + 0x3b bytes
mscorlib.dll!System.IO.StreamReader.ReadLine() + 0x13c bytes
> HGLib.dll!HGLib.HG.InvokeCommand(string workingDirectory = "D:\prj\xxx", string arguments, out System.Collections.Generic.List<string> resultList = Count = Cannot evaluate expression because a native frame is on top of the call stack.) Line 57 + 0x15 bytes C#
HGLib.dll!HGLib.HG.QueryFileStatus(string[] fileList = {string[90]}, out System.Collections.Generic.Dictionary<string,char> fileStatusDictionary = Count = Cannot evaluate expression because a native frame is on top of the call stack.) Line 289 + 0x32 bytes C#
HGLib.dll!HGLib.HGStatus.UpdateDirtyFilesStatus() Line 576 + 0x1e bytes C#
HGLib.dll!HGLib.HGStatus.DirectoryStatusCheckerProc(object stateInfo = {System.Threading.AutoResetEvent}) Line 465 + 0x8 bytes C#
mscorlib.dll!System.Threading._TimerCallback.TimerCallback_Context(object state) + 0x2f bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6f bytes
mscorlib.dll!System.Threading._TimerCallback.PerformTimerCallback(object state) + 0x6b bytes
Comment by: Bernd Schrader | Posted: Saturday, 27 June 2009, 01:33PM (27/06/2009)
Hi DM,
please get the latest code and confirm if the following fix works for you.
Bernd
------
Removed not absolute needed file-created event handler from the DirectoryWatcher
to avoid testing of compiler generated intermediate files against the HG repo.
This should solve the problem of #340.
To avoid testing of intermediate compiler files by HG, place an entry
into the .hgignore file e.G.
syntax: regexp
bin/Debug
bin/Release
Comment by: Bernd Schrader | Posted: Saturday, 27 June 2009, 01:40PM (27/06/2009)
{{{
As I can see, "dirty files" are checked against the hg-database (files in /debug/, /obj/, ...) - why? They are not in the hg-database...
}}
This is to find out that these files are 'not versioned'.
Comment by: DM | Posted: Tuesday, 07 July 2009, 08:11AM (07/07/2009)
I got a new version of TortoiseHG now, the problem didn't even occur with VisualHG 1.0.5.
About the 'dirty files': My understanding of the plugin is that it shows the status of all files in the project and provides basic control of the mercurial database. In my opinion it should be enough to check all files which are in the project/solution?
Just an idea, the plugin works great now!
Comment by: DM | Posted: Tuesday, 07 July 2009, 08:13AM (07/07/2009)
I meant, it didn't appear with TortoiseHG 0.8 and VisualHG 1.0.5.
With TortoiseHG 0.7.x and VisualHG 1.0.5 it happened. Maybe the "status -a" is non-blocking now...
Comment by: Bernd Schrader | Posted: Wednesday, 08 July 2009, 05:46PM (08/07/2009)
Yes, you're right, it should be enough to check only files of the projects.
But I found out with my 'sonny' solution with about 7000 files (cpp) in 50 projects
this is the most stable and also well performing way to track all these states.
Thank you for your posting.